Optimización de la puerta de enlace de archivo de S3 para copias de seguridad de bases de datos de SQL Server - AWS Storage Gateway
Implementar la puerta de enlace en la misma ubicación que los servidores SQLReducir los cuellos de botella causados por la lentitud de los discosAjustar 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éMejorar el rendimiento de los clientes de SMB mediante el ajuste del nivel de seguridad de la puerta de enlace de archivo de S3Mejorar el rendimiento de los de clientes SMB mediante la división de las copias de seguridad de SQL en varios archivosEvitar errores al copiar archivos de gran tamaño mediante el aumento la configuración de tiempo de espera de SMBAumentar el número de subprocesos del cargador de Amazon S3Desactivar la actualización automática de la cachéImplementar varias puertas de enlace para soportar la carga de trabajoRecursos adicionales para cargas de trabajo de copia de seguridad de bases de datos

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.

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

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

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 rendimiento de E/S, lo que puede mejorar significativamente la velocidad y la eficiencia de la copia 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:

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.

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

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

  • Se recomienda realizar una prueba de concepto 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