Optimización de S3 File Gateway para las 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 S3 File Gateway, que proporciona una retención 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 costos de los niveles de almacenamiento según sea necesario. Con esta solución, puede reducir la necesidad de aplicaciones de backup empresariales mediante herramientas integradas, como SQL Server Management Studio y Oracle RMAN.

En las siguientes secciones se describen las mejores prácticas para ajustar la implementación de S3 File Gateway a fin de optimizar el rendimiento y ofrecer un soporte rentable para cientos de terabytes de copias de seguridad de bases de datos SQL. La guía 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 servidores SQL

Recomendamos implementar su dispositivo virtual S3 File Gateway en una ubicación física con la menor latencia de red posible entre este y sus servidores SQL. 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 SMB, como los servidores SQL.

• 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 servidores SQL 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 S3 File Gateway 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.

Mejore el rendimiento de los clientes SMB ajustando el nivel de seguridad de su S3 File Gateway

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.

Mejore el rendimiento de los clientes SMB dividiendo las copias de seguridad de SQL en varios archivos

• Es difícil lograr el máximo rendimiento con una puerta de enlace de archivos 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, recomendamos usar varios subprocesos de cada servidor SQL para escribir varios archivos en paralelo y usar varios servidores SQL simultáneamente en su S3 File Gateway 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 S3 File Gateway. 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 archivos mediante comandos de T-SQL o 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 significativamente la velocidad y la eficiencia del respaldo.

Al configurar las copias de seguridad de un servidor 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:

• Realice copias de seguridad de SQL Server entre un 43 y un 67% más rápido al escribir en varios archivos

• Almacene fácilmente sus copias de seguridad de SQL Server en Amazon S3 mediante Puerta de enlace de archivo

Evite errores al copiar archivos de gran tamaño aumentando la configuración de tiempo de espera de SMB

Cuando S3 File Gateway copia archivos de copia de seguridad de SQL de gran tamaño en un recurso compartido de archivos SMB, la conexión del cliente SMB puede agotarse después de un período de tiempo prolongado. Recomendamos ampliar el tiempo de espera de sesión SMB para los clientes 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 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.

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

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

Implemente 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 múltiples 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 aumentando el número de subprocesos de carga de Amazon S3.

• 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 su carga de trabajo de backup de SQL, puede escalar la cantidad de puertas de enlace para cumplir con sus requisitos.

• Recomendamos 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 las cargas de trabajo de respaldo de bases de datos

• Almacene copias de seguridad de SQL Server en Amazon S3 mediante AWS Storage Gateway

• Almacene fácilmente sus copias de seguridad de SQL Server en Amazon S3 mediante Puerta de enlace de archivo

• Uso AWS Storage Gateway para almacenar copias de seguridad de bases de datos Oracle en Amazon S3

• Realice copias de seguridad de bases de datos de Oracle en Amazon S3 a escala

• Integre una base de datos SAP ASE en Amazon S3 mediante AWS Storage Gateway

• Cómo utiliza One AWS Hero las copias AWS Storage Gateway de seguridad en la nube

• Mejores prácticas de dimensionamiento de la caché de S3 File Gateway