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](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/).
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.
# Rendimiento y optimización
En esta sección se describen las directrices y las prácticas recomendadas para optimizar el rendimiento de la puerta de enlace de archivo.
**Topics**
+ [Guía básica de rendimiento para File Gateway](#performance-fgw)
+ [Optimizing Gateway Performance](#Optimizing-common)
+ [Maximización del rendimiento de la puerta de enlace de archivo de S3](Performance-Throughput.md)
+ [Optimización de la puerta de enlace de archivo de S3 para copias de seguridad de bases de datos de SQL Server](SQL-Backup-Best-Practices.md)
## Guía básica de rendimiento para File Gateway
En esta sección, encontrará instrucciones para el aprovisionamiento de hardware para su máquina virtual de FSx File Gateway. Las configuraciones de instancias que se indican en la tabla son ejemplos y se proporcionan como referencia.
Para un rendimiento óptimo, el tamaño del disco en caché debe ajustarse al tamaño del conjunto de trabajo activo. El uso de varios discos locales para la caché aumenta el rendimiento de escritura mediante el acceso en paralelo a los datos e incrementa la velocidad de E/S (IOPS).
**nota**
No recomendamos el uso del almacenamiento efímero. Para obtener información sobre el uso del almacenamiento efímero, consulte [Uso del almacenamiento efímero con puertas de enlace de EC2](ephemeral-disk-cache.md).
El límite de tamaño recomendado para los directorios individuales de los sistemas de archivos que se conectan a la puerta de enlace de archivo de 10 000 archivos por directorio. Puede usar la puerta de enlace de archivo con directorios que tengan más de 10 000 archivos, pero es posible que el rendimiento se vea afectado.
En la siguiente tabla, las operaciones de lectura de *aciertos de la caché* son lecturas de los datos de archivos que se obtienen desde la caché. Las operaciones *de lectura errónea de la caché* son lecturas de los datos de archivos que se proporcionan desde Amazon FSx para Windows File Server.
La siguiente tabla muestra un ejemplo de configuración de FSx File Gateway.
### FSx Rendimiento de File Gateway en clientes Windows
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/filegateway/latest/filefsxw/Performance.html)
**nota**
El rendimiento puede variar en función de la configuración de la plataforma de host y el ancho de banda de la red. El rendimiento de escritura disminuye con el tamaño del archivo, y el rendimiento más alto que se puede lograr para archivos pequeños (menos de 32 MiB) es de 16 archivos por segundo.
## Optimizing Gateway Performance
A continuaciónnuación encontrará información sobre cómo optimizar el rendimiento de la gateway. La orientación se basa en la adición de recursos a la gateway y la adición de recursos al servidor de aplicaciones.
### Añada recursos a la gateway
Puede optimizar el rendimiento de la gateway añadiendo recursos a la misma mediante uno o varios de los métodos siguientes.
**Utilice discos de mayor rendimiento**
Para optimizar el rendimiento de la puerta de enlace, puede añadir discos de alto rendimiento, como unidades de estado sólido (SSDs) y una NVMe controladora. También puede asociar discos virtuales a la MV directamente desde una red de área de almacenamiento (SAN) en lugar de Microsoft Hyper-V NTFS. La mejora del rendimiento del disco generalmente se traduce en un mejor rendimiento y en más input/output operaciones por segundo (IOPS). Para obtener más información sobre cómo agregar discos, consulte [Configuración de almacenamiento en caché adicional](ConfiguringLocalDiskStorage.md).
Para medir el rendimiento, utilice las métricas `ReadBytes` y `WriteBytes` con la estadística `Samples` de Amazon CloudWatch . Por ejemplo, la estadística `Samples` de la métrica `ReadBytes` durante un periodo muestra de 5 minutos, dividida por 300 segundos devuelve las IOPS. Por regla general, cuando revise estas métricas por una gateway, busque tendencias de bajo rendimiento y bajas IOPS, que indican cuellos de botella.
CloudWatch las métricas no están disponibles para todas las puertas de enlace. Para obtener información sobre métricas de puertas de enlace, consulte [Supervisión de su puerta de enlace de ](monitoring-file-gateway.md).
**Añada recursos de CPU al host de la gateway**
El requisito mínimo para un servidor de alojamiento de gateway son cuatro procesadores virtuales. Para optimizar el rendimiento de la gateway, compruebe que los cuatro procesadores virtuales asignados a la máquina virtual de la gateway están respaldados por cuatro núcleos. Además, confirme que no está sobresuscribiendo el servidor CPUs anfitrión.
Cuando agrega más CPUs al servidor host de la puerta de enlace, aumenta la capacidad de procesamiento de la puerta de enlace. De este modo, la puerta de enlace podrá gestionar, paralelamente, el almacenamiento de los datos de la aplicación en el almacenamiento local y la carga de estos datos en para Windows File Server. CPUs Además, ayuda a garantizar que su puerta de enlace reciba suficientes recursos de CPU cuando el host se comparte con otros VMs. Proporcionar suficientes recursos de CPU tiene el efecto general de mejorar el rendimiento.
Storage Gateway admite el uso de 24 CPUs en el servidor host de la puerta de enlace. Puede usar 24 CPUs para mejorar significativamente el rendimiento de su puerta de enlace. Le recomendamos la siguiente configuración de gateway para el servidor de alojamiento de la gateway:
+ 24 CPUs.
+ 16 GiB de RAM reservada para puertas de enlace de archivo
+ 16 GiB de RAM reservados para puertas de enlace con un tamaño de caché de hasta 16 TiB
+ 32 GiB de RAM reservados para puertas de enlace con un tamaño de caché de 16 TiB a 32 TiB
+ 48 GiB de RAM reservados para puertas de enlace con un tamaño de caché de 32 TiB a 64 TiB
+ Disco 1 asociado a controlador paravirtual 1, que se utiliza como caché de la gateway de la manera siguiente:
+ SSD con un NVMe controlador.
+ Adaptador de red 1 configurado en red de MV 1:
+ Utilice la red VM 1 y añada VMXnet3 (10 Gbps) para utilizarla en la ingestión.
+ Adaptador de red 2 configurado en red de MV 2:
+ Utilice la red VM 2 y añada una VMXnet3 (10 Gbps) para conectarla. AWS
**Respalde los discos virtuales de la gateway con discos físicos independientes**
Cuando aprovisione discos para una puerta de enlace, le recomendamos encarecidamente que no aprovisione discos locales para el almacenamiento local que utilicen el mismo disco de almacenamiento físico subyacente. Por ejemplo VMware ESXi, los recursos de almacenamiento físico subyacentes se representan como un almacén de datos. Al implementar la máquina virtual de gateway, debe elegir el almacén de datos en el que se almacenarán los archivos de la máquina virtual. Cuando aprovisione un disco virtual (por ejemplo, como búfer de carga), puede almacenar el disco virtual en el mismo almacén de datos que la máquina virtual o en un almacén de datos diferente.
Si tiene más de un almacén de datos, le recomendamos encarecidamente que elija un almacén de datos para cada tipo de almacenamiento local que esté creando. Un almacén de datos respaldado por un único disco físico subyacente puede dar lugar a un bajo rendimiento. Por ejemplo, cuando se utiliza el mismo disco para respaldar tanto el almacenamiento en caché como para el búfer de carga en una configuración de gateway. Del mismo modo, un almacén de datos respaldado por una configuración RAID que no sea de alto rendimiento, como RAID 1, puede dar lugar a un bajo rendimiento.
### Añada recursos al entorno de aplicaciones
**Aumente el ancho de banda entre el servidor de aplicaciones y la gateway**
Para optimizar el rendimiento de la puerta de enlace, asegúrese de que el ancho de banda de la red entre la aplicación y la puerta de enlace puede sostener las necesidades de la aplicación. Puede utilizar las métricas `ReadBytes` y `WriteBytes` de la puerta de enlace para medir el rendimiento de datos total.
Para la aplicación, compare el rendimiento medido con el rendimiento deseado. Si el rendimiento medido es inferior al deseado, un aumento del ancho de banda entre la aplicación y la gateway puede aumentar el rendimiento si la red es el cuello de botella. Del mismo modo, puede aumentar el ancho de banda entre la MV y los discos locales, si no están conectados directamente.
**Añada recursos de CPU al entorno de aplicaciones**
Si la aplicación puede utilizar recursos de CPU adicionales, añadir más CPUs puede ayudar a la aplicación a escalar su I/O carga.
Algunas operaciones con archivos en la puerta de enlace de FSx archivos, como cambiar el nombre de las carpetas de nivel superior o los cambios de permisos, pueden provocar varias operaciones con archivos y provocar una I/O carga elevada en el sistema de archivos del servidor de archivos de Windows. FSx [Si el sistema de archivos no tiene suficientes recursos de rendimiento para su carga de trabajo, es posible que elimine las instantáneas, ya que da prioridad a la disponibilidad para la retención continua de instantáneas por I/O encima de la histórica.](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)
En la FSx consola de Amazon, consulta la página **Supervisión y rendimiento** para ver si tu sistema de archivos está insuficientemente aprovisionado. Si es así, puede cambiar a un almacenamiento en SSD, aumentar la capacidad de rendimiento o aumentar las IOPS en SSD para gestionar su carga de trabajo.
# 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 no son interdependientes, se han seleccionado y ordenado de forma lógica para probar y ajustar las implementaciones de S3 File Gateway. Soporte 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 S3 File Gateway como una máquina virtual local en su VMware entorno KVM de Microsoft Hyper-V o Linux, o en la AWS nube 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 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.
## 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) en la Guía del usuario de Amazon Elastic Compute Cloud.
## Reducir 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 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` 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html) 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 riesgo`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 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 a cargas de trabajo más grandes, se recomienda 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 métrica `UserCpuPercent`. Para obtener más información, consulte [Descripción de métricas de la puerta de enlace](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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 NVMe un 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 las [mejores prácticas de tamaño de caché de S3 File Gateway](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) en el YouTube canal oficial 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).
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](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-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 proporción ideal price-to-performance. Para cambiar el tipo de instancia, utilice el siguiente procedimiento en la consola de Amazon EC2:
1. Detenga la instancia de Amazon EC2.
1. Cambie el tipo de instancia de Amazon EC2.
1. 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 price-to-performance proporción de una instancia Amazon EC2 se refiere a la potencia de cálculo que obtiene por el precio que paga. Por lo general, las instancias Amazon EC2 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.
## Ajustar el nivel de seguridad de SMB
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 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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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, 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 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 múltiples vCPUs, 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/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 hilos 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`)
+ Se ejecuta durante 300 segundos (`-d300`)
+ Realiza una I/O prueba 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](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113) 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 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 la I/O profundidad 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 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 del manual de Linux [fio](https://linux.die.net/man/1/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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).
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 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 métricas de la puerta de enlace](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
**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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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 rendimiento alto I/O y bajo.
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
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](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html).
**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](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares).
+ 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.
# Optimización de la puerta de enlace de archivo de S3 para copias de seguridad de bases de datos de SQL Server
Las copias de seguridad de bases de datos son un caso de uso común y recomendado para la puerta de enlace de archivo de S3, que proporciona una retención de datos rentable a corto y largo plazo al almacenar las copias de seguridad de las bases de datos en Amazon S3, con la capacidad de cambiar el ciclo de vida para reducir los costes de los niveles de almacenamiento según sea necesario. Con esta solución, puede reducir la necesidad de aplicaciones de copia de seguridad empresariales mediante herramientas integradas, como SQL Server Management Studio y Oracle RMAN.
En las siguientes secciones se describen las prácticas recomendadas para ajustar la implementación de la puerta de enlace de archivo de S3 a fin de optimizar el rendimiento y ofrecer un soporte rentable para cientos de terabytes de copias de seguridad de bases de datos de SQL. 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 no son interdependientes, se han seleccionado y ordenado de forma lógica para probar y ajustar las implementaciones de S3 File Gateway. Soporte 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 S3 File Gateway como una máquina virtual local en su VMware entorno KVM de Microsoft Hyper-V o Linux, o en la AWS nube 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 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.
## Implementar la puerta de enlace en la misma ubicación que los servidores SQL
Recomendamos 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 los servidores SQL. 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 SMB, como los servidores SQL.
+ 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 servidores SQL en el mismo grupo de ubicación. Para obtener más información, consulte [Grupos de ubicación para instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) en la Guía del usuario de Amazon Elastic Compute Cloud.
## Reducir 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 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` 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](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html) 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 riesgo`IoWaitPercent`.
## Ajustar la asignación de recursos de la máquina virtual de puerta de enlace de archivo de S3 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 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 a cargas de trabajo más grandes, se recomienda 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 métrica `UserCpuPercent`. Para obtener más información, consulte [Descripción de métricas de la puerta de enlace](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
+ 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 NVMe un 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 las [mejores prácticas de tamaño de caché de S3 File Gateway](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln) en el YouTube canal oficial 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](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html).
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](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-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 proporción ideal price-to-performance. Para cambiar el tipo de instancia, utilice el siguiente procedimiento en la consola de Amazon EC2:
1. Detenga la instancia de Amazon EC2.
1. Cambie el tipo de instancia de Amazon EC2.
1. 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 price-to-performance proporción de una instancia Amazon EC2 se refiere a la potencia de cálculo que obtiene por el precio que paga. Por lo general, las instancias Amazon EC2 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.
## Mejorar el rendimiento de los clientes de SMB mediante el ajuste del nivel de seguridad de la puerta de enlace de archivo de S3
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 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](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html).
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, 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 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 múltiples vCPUs, 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.
## Mejorar el rendimiento de los de clientes SMB mediante la división de las copias de seguridad de SQL en varios archivos
+ Es difícil lograr el máximo rendimiento con una puerta de enlace de archivo de S3 en la que solo un servidor SQL escribe un archivo a la vez, ya que la escritura secuencial desde un único servidor SQL es una operación de un solo subproceso. En su lugar, se recomienda usar varios subprocesos de cada servidor SQL para escribir varios archivos en paralelo y usar varios servidores SQL simultáneamente en la puerta de enlace de archivo de S3 para maximizar el rendimiento de la puerta de enlace. Con las copias de seguridad de SQL, la división de las copias de seguridad en varios archivos permite que cada archivo utilice un subproceso independiente, que escribirá varios archivos simultáneamente en el recurso compartido de archivos de la puerta de enlace de archivo de S3. Cuantos más subprocesos tenga, mayor rendimiento podrá lograr, hasta los límites de la puerta de enlace.
+ SQL Server permite escribir en varios archivos al mismo tiempo durante una sola operación de copia de seguridad. Por ejemplo, puede especificar varios destinos de archivo mediante comandos de T-SQL o mediante SQL Server Management Studio (SSMS). Cada archivo utiliza un subproceso independiente para enviar los datos desde el servidor SQL al recurso compartido de archivos de la puerta de enlace. Este enfoque permite un mejor I/O rendimiento, lo que puede mejorar considerablemente la velocidad y la eficiencia de las copias de seguridad.
Al configurar las copias de seguridad de los servidores SQL, tenga en cuenta lo siguiente:
+ Al dividir las copias de seguridad en varios archivos, los administradores de SQL Server pueden optimizar los tiempos de las copias de seguridad y administrar las copias de seguridad de grandes bases de datos de manera más eficaz.
+ La cantidad de archivos utilizados depende de la configuración de almacenamiento y de los requisitos de rendimiento del servidor. Para bases de datos de gran tamaño, recomendamos dividir las copias de seguridad en varios archivos más pequeños de entre 10 GB y 20 GB cada uno.
+ No hay un límite estricto en cuanto al número de archivos en los que SQL Server puede escribir durante una copia de seguridad, pero esta elección debe basarse en consideraciones prácticas, como la arquitectura de almacenamiento y el ancho de banda de la red.
Para obtener más información, consulte lo siguiente:
+ [Realizar copias de seguridad de SQL Server entre un 43 y un 67 % más rápido al escribir en varios archivos](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [Almacene fácilmente sus copias de seguridad de SQL Server en Amazon S3 mediante Puerta de enlace de archivo](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## Evitar errores al copiar archivos de gran tamaño mediante el aumento la configuración de tiempo de espera de SMB
Cuando la puerta de enlace de archivo de S3 copia archivos de copia de seguridad de SQL 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 de SQL Server 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](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails).
## 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 servidores SQL 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 métricas de la puerta de enlace](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics).
**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.
## 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](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html).
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 servidores SQL. 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.
## Implementar varias puertas de enlace para soportar la carga de trabajo
Storage Gateway puede admitir copias de seguridad de SQL para entornos grandes con cientos de bases de datos SQL, varios servidores SQL y cientos de terabytes de datos de copia de seguridad al dividir la carga de trabajo en varias puertas de enlace.
Al planificar una implementación con varias puertas de enlace y servidores SQL, tenga en cuenta lo siguiente:
+ Por lo general, una sola puerta de enlace puede cargar hasta 20 TB por día, con suficientes recursos de hardware y ancho de banda. Puede aumentar este límite hasta 40 TB por día mediante el [aumento del número de subprocesos del cargador de Amazon S3](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads).
+ Recomendamos realizar una proof-of-concept prueba para medir el rendimiento y tener en cuenta todas las variables de la implementación. Después de determinar el rendimiento máximo de la carga de trabajo de copia de seguridad de SQL, puede escalar la cantidad de puertas de enlace para cumplir con sus requisitos.
+ Se recomienda diseñar la solución teniendo en cuenta el crecimiento, ya que la cantidad y el tamaño de las bases de datos pueden aumentar con el tiempo. Para seguir escalando y soportando una carga de trabajo cada vez mayor, puede implementar puertas de enlace adicionales según sea necesario.
## Recursos adicionales para cargas de trabajo de copia de seguridad de bases de datos
+ [Almacene copias de seguridad de SQL Server en Amazon S3 mediante AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [Almacene fácilmente sus copias de seguridad de SQL Server en Amazon S3 mediante Puerta de enlace de archivo](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [Uso AWS Storage Gateway para almacenar copias de seguridad de bases de datos Oracle en Amazon S3](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Realización de copias de seguridad de bases de datos Oracle en Amazon S3 a escala](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [Integre una base de datos SAP ASE en Amazon S3 mediante AWS Storage Gateway](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [Cómo utiliza One AWS Hero las copias AWS Storage Gateway de seguridad en la nube](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [Prácticas recomendadas de dimensionamiento de la caché de la puerta de enlace de archivo de S3](https://www.youtube.com/watch?v=-ibL1eEcROI)