Administración de recursos en grupos elásticos densos

Se aplica a: Azure SQL Database

Los grupos elásticos de Azure SQL Database son una solución rentable para administrar muchas bases de datos con un uso de recursos variable. Todas las bases de datos de un grupo elástico comparten la misma asignación de recursos, como CPU, memoria, subprocesos de trabajo, espacio de almacenamiento o tempdb, suponiendo que solo un subconjunto de bases de datos del grupo usa recursos de proceso en un momento dado. Este supuesto permite que los grupos elásticos sean rentables. En lugar de pagar por todos los recursos que podría necesitar cada base de datos individual, los clientes pagan por un conjunto de recursos mucho más pequeño, que comparten todas las bases de datos del grupo.

Regulación de recursos

El uso compartido de recursos requiere que el sistema controle cuidadosamente el uso de recursos para minimizar el efecto de "vecino ruidoso", donde una base de datos con un consumo elevado de recursos afecta a otras bases de datos del mismo grupo elástico. Azure SQL Database logra estos objetivos mediante la implementación de la gobernanza de recursos. Al mismo tiempo, el sistema debe proporcionar recursos suficientes para características como alta disponibilidad y recuperación ante desastres (HADR), copia de seguridad y restauración, supervisión, Almacén de consultas y ajuste automático, entre otros, para que funcione de manera confiable.

El objetivo de diseño principal de los grupos elásticos es la rentabilidad. Por esta razón, el sistema permite a los clientes de forma intencionada crear grupos densos, es decir, grupos con un número de bases de datos que se aproximen o alcancen el máximo permitido, pero con una asignación moderada de recursos de proceso. Por la misma razón, el sistema no reserva todos los recursos potencialmente necesarios para sus procesos internos, sino que permite que se compartan entre estos procesos y las cargas de trabajo de usuario.

Este enfoque permite que los clientes usen grupos elásticos densos para conseguir un rendimiento adecuado y mayores ahorros en los costos. Sin embargo, si la carga de trabajo en muchas bases de datos de un grupo denso es suficientemente intensa, la contención de recursos puede ser considerable. La contención de recursos reduce el rendimiento de la carga de trabajo del usuario y puede afectar de forma negativa a los procesos internos.

Cuando se produce la contención de recursos en un grupo empaquetado de forma densa, los clientes pueden elegir una o varias de las siguientes acciones para mitigarla:

• Ajuste la carga de trabajo de consulta para reducir el consumo de recursos o divida el consumo de recursos entre varias bases de datos a lo largo del tiempo.
• Reducir la densidad del grupo trasladando algunas bases de datos a otro grupo o convirtiéndolas en bases de datos independientes.
• Escalar verticalmente el grupo para obtener más recursos.

Para obtener sugerencias sobre cómo implementar las dos últimas acciones, consulte Recomendaciones operativas más adelante en este artículo. La reducción de la contención de recursos beneficia tanto a las cargas de trabajo de los usuarios como a los proceso internos, y permite que el sistema mantenga de manera confiable el nivel de servicio esperado.

Supervisión del consumo de recursos

Para evitar la degradación del rendimiento debido a la contención de recursos, los clientes que usen grupos elásticos densos deben supervisar proactivamente el consumo de recursos y realizar acciones oportunas si el aumento de esta empieza a afectar a las cargas de trabajo. La supervisión continua es importante porque el uso de recursos en un grupo cambia con el tiempo debido a los cambios en la carga de trabajo del usuario, los cambios en los volúmenes de datos y la distribución, los cambios en la densidad del grupo y los cambios en servicio Azure SQL Database.

Azure SQL Database proporciona varias métricas que son de interés para este tipo de supervisión. Superar el valor medio recomendado de cada métrica indica la contención de recursos en el grupo y se debe solucionar mediante una de las acciones mencionadas anteriormente.

Para enviar una alerta cuando el uso de recursos del grupo (CPU, E/S de datos, E/S de registro, roles de trabajo, etc.) supera un umbral, considere la posibilidad de crear alertas a través de Azure Portal o el cmdlet Add-AzMetricAlertRulev2 de PowerShell. Al supervisar grupos elásticos, considere también la posibilidad de crear alertas para bases de datos individuales del grupo si es necesario en su escenario. Para obtener un escenario de ejemplo para la supervisión de grupos elásticos, consulte Supervisión y administración del rendimiento de Azure SQL Database en una aplicación SaaS multiinquilino.

Además de estas métricas, Azure SQL Database proporciona una vista que devuelve los límites reales de la regulación de recursos, así como vistas adicionales que devuelven estadísticas de uso de recursos en el nivel de grupo de recursos y en el nivel de grupo de cargas de trabajo.

Estas vistas se pueden usar para supervisar el uso de recursos y solucionar problemas de contención de recursos casi en tiempo real. La carga de trabajo de usuario de las réplicas primarias y secundarias legibles, incluidas las réplicas geográficas, se clasifica en el grupo de recursos SloSharedPool1 y en el grupo de cargas de trabajo UserPrimaryGroup.DBId[N], donde N representa el valor del identificador de base de datos.

Además de supervisar el uso de recursos actual, los clientes que usan grupos densos pueden mantener datos de uso de recursos históricos en un almacén de datos independiente. Estos datos se pueden usar en análisis predictivos para administrar de forma proactiva el uso de recursos en función de las tendencias históricas y estacionales.

Recomendaciones operativas

Deje suficiente espacio para los recursos. En caso de producirse contención de recursos y degradación del rendimiento, la mitigación puede implicar sacar algunas bases de datos fuera del grupo elástico afectado o escalar verticalmente el grupo, como se indicó anteriormente. Sin embargo, para realizar estas acciones se requieren recursos de proceso adicionales. En concreto, en el caso de los grupos Premium y Crítico para la empresa, estas acciones requieren la transferencia de todos los datos de las bases de datos que se van a migrar o de todas las bases de datos del grupo elástico si el grupo se escala verticalmente. La transferencia de datos es una operación de larga duración que consume muchos recursos. Si el grupo ya tiene una elevada presión de recursos, la operación de mitigación en sí reducirá el rendimiento aún más. En casos extremos, puede que no sea posible resolver la contención de recursos mediante la migración de la base de datos o el escalado horizontal del grupo, ya que los recursos necesarios no están disponibles. En este caso, puede que la única solución pase por reducir temporalmente la carga de trabajo de consultas en el grupo elástico afectado.

Los clientes que usen grupos densos deben supervisar de cerca las tendencias de utilización de recursos descritas anteriormente y llevar a cabo acciones de mitigación mientras las métricas permanezcan dentro de los intervalos recomendados y todavía haya suficientes recursos en el grupo elástico.

La utilización de recursos depende de varios factores que cambian con el tiempo en cada base de datos y cada grupo elástico. Conseguir una relación óptima de precio/rendimiento en grupos densos requiere una supervisión y un reequilibrio continuos, que suponen migrar las bases de datos de los grupos más utilizados a los menos utilizados y crear grupos según sea necesario para dar cabida a una mayor carga de trabajo.

No mueva las bases de datos "activas" . Si la contención de recursos en el nivel de grupo se debe principalmente a un número pequeño de bases de datos muy utilizadas, puede ser tentador migrar estas bases de datos a un grupo menos utilizado o convertirlas en bases de datos independientes. Sin embargo, no es el enfoque recomendado mientras una base de datos presente una utilización muy alta, ya que la operación de migración disminuirá aún más el rendimiento, tanto para la base de datos que se migra como para todo el grupo. En su lugar, espere a que la alta utilización disminuya o migre las bases de datos menos utilizadas en lugar de aligerar la presión de los recursos en el nivel de grupo. Sin embargo, mover las bases de datos con una utilización muy baja no proporciona ninguna ventaja en este caso, ya que no reduce sustancialmente la utilización de recursos en el nivel de grupo.

Cree bases de datos en un grupo de "cuarentena" . En escenarios donde se crean con frecuencia bases de datos, como las aplicaciones que usan el modelo de inquilino por base de datos, existe el riesgo de que una nueva base de datos colocada en un grupo elástico existente consuma inesperadamente una cantidad considerable de recursos y afecte a otras bases de datos y procesos internos del grupo. Para mitigar este riesgo, cree un grupo de "cuarentena" aparte con asignación amplia de recursos. Use este grupo con bases de datos nuevas en las que se desconozcan los patrones de consumo de recursos. Una vez que una base de datos se ha mantenido en este grupo durante un ciclo comercial, como una semana o un mes, y se conoce su consumo de recursos, se puede migrar a un grupo con capacidad suficiente como para dar cabida a este uso adicional de recursos.

Supervise el espacio usado y asignado. Cuando el espacio de grupo asignado (tamaño total de todos los archivos de base de datos en almacenamiento para todas las bases de datos de un grupo) alcanza el tamaño máximo del grupo, pueden producirse errores de espacio insuficiente. Si el espacio asignado tiende a ser alto y está en camino de alcanzar el tamaño máximo del grupo, las opciones de mitigación incluyen:

• Sacar algunas bases de datos del grupo para reducir el espacio total asignado
• Reducir archivos de base de datos para limitar el espacio asignado vacío en los archivos
• Escalar verticalmente el grupo a un objetivo de servicio con un tamaño de grupo máximo mayor

Si el espacio de grupo utilizado (tamaño total de datos en todas las bases de datos de un grupo, sin incluir el espacio vacío en los archivos) tiende a ser alto y está en camino de alcanzar el tamaño máximo del grupo, las opciones de mitigación incluyen:

• Sacar algunas bases de datos del grupo para reducir el espacio total utilizado
• Sacar (archivar) datos de la base de datos o eliminar los datos que ya no sean necesarios
• Implementar la compresión de datos
• Escalar verticalmente el grupo a un objetivo de servicio con un tamaño de grupo máximo mayor

Evite servidores demasiado densos. Azure SQL Database admite hasta 5000 bases de datos por servidor. Los clientes que usan grupos elásticos con miles de bases de datos podrían colocar varios grupos elásticos en un solo servidor, con el número total de bases de datos hasta el límite admitido. Sin embargo, los servidores con muchos miles de bases de datos presentan complicaciones operativas. Las operaciones que requieren la enumeración de todas las bases de datos de un servidor, por ejemplo, la visualización de las bases de datos en el portal, serán más lentas. Los errores operativos, como la modificación incorrecta de los inicios de sesión de nivel de servidor o las reglas de firewall, afectarán a un mayor número de bases de datos. La eliminación accidental del servidor requerirá la asistencia del servicio de soporte técnico de Microsoft para recuperar las bases de datos del servidor eliminado y provocará una interrupción prolongada en todas las bases de datos afectadas.

Limite el número de bases de datos por servidor a un número menor que el máximo admitido. En muchos escenarios, el uso de hasta 1000 o 2000 bases de datos por servidor se considera óptimo. Para reducir la probabilidad de eliminación accidental del servidor, coloque un bloqueo de eliminación en el servidor o en su grupo de recursos.

Ejemplos

Visualización de la configuración de capacidad de la base de datos individual

Use la vista de administración dinámica sys.dm_user_db_resource_governance para ver la configuración real y la configuración de capacidad que usa la gobernanza de recursos en la base de datos o el grupo elástico actual. Para más información, consulte sys.dm_user_db_resource_governance.

Ejecute esta consulta en cualquier base de datos de un grupo elástico. Todas las bases de datos del grupo tienen la misma configuración de gobernanza de recursos.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Supervisión del consumo general de recursos del grupo elástico

Use la vista de catálogo del sistema sys.elastic_pool_resource_stats para supervisar el consumo de recursos de todo el grupo. Para más información, consulte sys.elastic_pool_resource_stats.

Esta consulta de ejemplo para ver los últimos 10 minutos debe ejecutarse en la base de datos master del servidor lógico de Azure SQL que contiene el grupo elástico deseado.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Supervisión del consumo de recursos de una base de datos individual

Use la vista de administración dinámica sys.dm_db_resource_stats para supervisar el consumo de recursos de bases de datos individuales. Para más información, consulte sys.dm_db_resource_stats. Hay una fila para cada 15 segundos, incluso si no hay ninguna actividad. Los datos históricos se mantienen aproximadamente durante una hora.

Esta consulta de ejemplo para ver los últimos 10 minutos de datos debe ejecutarse en la base de datos de su elección.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Para un tiempo de retención más largo con una frecuencia menor, considere la siguiente consulta en sys.resource_stats y ejecute en la base de datos master del servidor lógico de Azure SQL. Para más información, consulte sys.resource_stats (Azure SQL Database). Existe una fila cada cinco minutos y los datos históricos se mantienen durante dos semanas.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Supervisión del uso de memoria

Esta consulta calcula la métrica oom_per_second de cada grupo de recursos para el historial reciente, en función del número de instantáneas disponibles. Esta consulta de ejemplo ayuda a identificar el número medio reciente de asignaciones de memoria con errores en el grupo. Se puede ejecutar en cualquier base de datos de un grupo elástico.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Supervisión de la utilización del espacio de registros tempdb

Esta consulta devuelve el valor actual de la métrica tempdb_log_used_percent, que muestra la utilización relativa del registro de transacciones tempdb con respecto al tamaño máximo permitido. Se puede ejecutar en cualquier base de datos de un grupo elástico.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Pasos siguientes

• Se puede encontrar una introducción a los grupos elásticos en Los grupos elásticos pueden ayudarle a administrar y escalar varias bases de datos de Azure SQL Database.
• Para información sobre cómo optimizar las cargas de trabajo de consultas para reducir la utilización de recursos, consulte Supervisión y ajuste y Optimización de la supervisión y el rendimiento.