Compartir a través de

Introducción a los grupos elásticos de Hiperescala en Azure SQL Database

  • Artículo

Se aplica a: Azure SQL Database

En este artículo se proporciona información general sobre los grupos elásticos de Hiperescala en Azure SQL Database.

Un grupo elástico de Azure SQL Database permite a los desarrolladores de software como servicio (SaaS) optimizar la relación rendimiento-precio para un grupo de bases de datos dentro de un presupuesto prescrito a la vez que se ofrece elasticidad de rendimiento para cada base de datos. Los grupos elásticos de Hiperescala para Azure SQL Database presentan un modelo de recursos compartidos para las bases de datos de Hiperescala.

Para obtener ejemplos para crear, escalar o mover bases de datos a un grupo elástico de Hiperescala mediante la CLI de Azure o PowerShell, consulte Uso de grupos elásticos de Hiperescala mediante herramientas de línea de comandos.

Para obtener más información sobre la disponibilidad general de grupos elásticos de Hiperescala, consulte Blog: disponibilidad general de grupos elásticos de Hiperescala.

Información general

Implemente la base de datos de Hiperescala en un grupo elástico para compartir recursos entre las bases de datos del grupo y optimizar el costo de tener varias bases de datos con diferentes patrones de uso.

Escenarios de uso de un grupo elástico con las bases de datos de Hiperescala:

  • Cuando necesite escalar o reducir verticalmente los recursos de proceso asignados al grupo elástico en un período de tiempo predecible, independientemente de la cantidad de almacenamiento asignado.
  • Cuando desee escalar horizontalmente los recursos de proceso asignados al grupo elástico agregando una o varias réplicas de escalado de lectura.
  • Si desea usar un alto rendimiento del registro de transacciones para cargas de trabajo con un uso intensivo de escritura, incluso con recursos de proceso inferiores.

La adición de bases de datos que no son de Hiperescala a un grupo elástico de Hiperescala convierte las bases de datos en el nivel de servicio de Hiperescala.

Arquitectura

Tradicionalmente, la arquitectura de una base de datos de Hiperescala independiente consta de tres componentes independientes principales: proceso, almacenamiento ("Servidores de páginas") y registro ("Servicio de registro"). Al crear un grupo elástico para las bases de datos de Hiperescala, las bases de datos del grupo comparten recursos de proceso y registro. Además, si decide configurar la alta disponibilidad, cada grupo de alta disponibilidad se crea con un conjunto equivalente e independiente de recursos de proceso y registro.

A continuación se describe la arquitectura de un grupo elástico para bases de datos de Hiperescala:

  • Un grupo elástico de Hiperescala consta de un grupo principal que aloja las bases de datos principales de Hiperescala y, si están configurados, hasta cuatro grupos de alta disponibilidad adicionales.
  • Las bases de datos principales de Hiperescala hospedadas en el grupo elástico principal comparten el proceso del motor de base de datos de SQL Server (sqlservr.exe), los núcleos virtuales, la memoria y la memoria caché ssd.
  • La configuración de alta disponibilidad del grupo principal crea grupos de alta disponibilidad adicionales que contienen réplicas de base de datos de solo lectura para las bases de datos del grupo principal. Cada grupo principal puede tener un máximo de cuatro grupos de réplicas de alta disponibilidad. Cada grupo de alta disponibilidad comparte recursos de proceso, caché SSD y memoria para todas las bases de datos secundarias de solo lectura del grupo.
  • Las bases de datos de Hiperescala del grupo elástico principal comparten el mismo servicio de registro. Dado que las bases de datos de los grupos de alta disponibilidad no tienen ninguna carga de trabajo de escritura, no usan el servicio de registro.
  • Cada base de datos de Hiperescala tiene su propio conjunto de servidores de páginas y estos servidores de páginas se comparten entre la base de datos principal del grupo principal y todas las bases de datos de réplica secundaria del grupo de alta disponibilidad.
  • Las bases de datos secundarias de Hiperescala con replicación geográfica se pueden colocar dentro de otro grupo elástico.
  • Al especificar ApplicationIntent=ReadOnly en la cadena de conexión de la base de datos, se le dirige a una base de datos de réplica de solo lectura en uno de los grupos de alta disponibilidad.

En el diagrama siguiente se muestra la arquitectura de un grupo elástico para bases de datos de Hiperescala:

Diagrama que muestra la arquitectura de un grupo elástico de Hiperescala.

Administración de bases de datos de grupos elásticos de Hiperescala

Puede usar los mismos comandos para administrar las bases de datos agrupadas de Hiperescala que para las bases de datos agrupadas de los demás niveles de servicio. Asegúrese de que especifica Hyperscale para la edición al crear el grupo elástico de Hiperescala.

La única diferencia es la capacidad de modificar el número de réplicas de alta disponibilidad para un grupo elástico de Hiperescala existente. Para ello:

Puede usar las siguientes herramientas de cliente para administrar las bases de datos de Hiperescala de un grupo elástico:

Conversión de bases de datos que no son de Hiperescala a grupos elásticos de Hiperescala

Al convertir una base de datos a Hiperescala, puede agregar la base de datos a un grupo elástico de Hiperescala existente. Para estas conversiones, el grupo elástico de Hiperescala debe existir en el mismo servidor lógico que la base de datos de origen.

Al convertir bases de datos a grupos elásticos de Hiperescala, tenga en cuenta el número máximo de bases de datos por grupo elástico de Hiperescala.

Conversión de bases de datos que no son de Hiperescala a grupos elásticos de Hiperescala mediante T-SQL

Puede utilizar comandos T-SQL para convertir varias bases de datos de uso general y agregarlas a un grupo elástico de Hiperescala existente denominado hsep1:

ALTER DATABASE gpepdb1 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb2 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb3 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb4 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))

En este ejemplo, va a solicitar implícitamente una conversión de uso general a Hiperescala especificando que el destino SERVICE_OBJECTIVE es un grupo elástico de Hiperescala. Cada uno de los comandos anteriores comienza a convertir la base de datos de uso general correspondiente a Hiperescala. Estos comandos ALTER DATABASE vuelven rápidamente y no esperan a que se complete la conversión. En el ejemplo que se muestra, tendría cuatro conversiones de uso general a Hiperescala ejecutándose en paralelo.

Puede consultar la vista de administración dinámica sys.dm_operation_status para supervisar el estado de estas operaciones de conversión en segundo plano.

Conversión de bases de datos que no son de Hiperescala a grupos elásticos de Hiperescala mediante PowerShell

Puede utilizar comandos de PowerShell para convertir varias bases de datos de uso general y agregarlas a un grupo elástico de Hiperescala existente denominado hsep1. Por ejemplo, la secuencia de comandos de muestra a continuación sigue estos pasos:

  1. Utilice el cmdlet Get-AzSqlElasticPoolDatabase para enumerar todas las bases de datos del grupo elástico de uso general denominado gpep1.
  2. El cmdlet Where-Object filtra la lista solo para aquellos nombres de bases de datos que comienzan con gpepdb.
  3. Para cada base de datos, el cmdlet Set-AzSqlDatabase inicia una conversión. En este caso, va a solicitar implícitamente una conversión al nivel de servicio Hiperescala especificando el grupo elástico de Hiperescala de destino denominado hsep1.
    • El parámetro -AsJob permite que cada una de las solicitudes Set-AzSqlDatabase se ejecuten en paralelo. Si prefiere ejecutar las conversiones una por una, puede eliminar el parámetro -AsJob.
$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1"
$dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | % { Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName "hsep1" -AsJob }

Además de la vista de administración dinámica sys.dm_operation_status, puede utilizar el cmdlet de PowerShell Get-AzSqlDatabaseActivity para supervisar el estado de estas operaciones de conversión en segundo plano.

Límites de recursos

A continuación se enumeran los límites admitidos para trabajar con bases de datos de Hiperescala dentro de grupos elásticos:

  • Generación de hardware compatible: serie estándar (Gen5), serie Premium y memoria de la serie Premium optimizada.
  • Máximo de núcleos virtuales por grupo: 80 o 128 núcleos virtuales, según el objetivo de nivel de servicio.
  • Tamaño máximo de datos admitido por base de datos: 100 TB.
  • Tamaño máximo de datos total admitido entre bases de datos del grupo: 100 TB.
  • Rendimiento máximo admitido del registro de transacciones por base de datos: 100 MB.
  • Rendimiento máximo total admitido del registro de transacciones entre bases de datos del grupo: 131,25 MB/segundo.
  • Cada grupo elástico de Hiperescala puede tener hasta 25 bases de datos.

Para obtener más información, consulte los límites de recursos de los grupos elásticos de Hiperescala para la serie estándar, la serie Premium y la memoria de la serie Premium optimizada.

Limitaciones

Tenga en cuenta las limitaciones siguientes:

  • No se admite el cambio de un grupo elástico existente que no sea de Hiperescala a la edición Hiperescala. En la sección de conversión se indican alternativas que puede utilizar.
  • No se admite el cambio de edición de un grupo elástico de Hiperescala a una edición que no sea Hiperescala.
  • Para realizar la "migración inversa" de una base de datos válida que se encuentra en un grupo elástico de Hiperescala, primero debe quitarse de este grupo elástico. La base de datos de Hiperescala independiente se puede migrar de forma inversa a una base de datos independiente de uso general.
  • Para el nivel de servicio Hiperescala, la compatibilidad con redundancia de zona solo se puede especificar durante la creación de la base de datos o el grupo elástico y no se puede modificar una vez que se aprovisione el recurso. Para más información, consulte Migración de base de datos de Azure SQL para compatibilidad con zonas de disponibilidad.
  • No se admite la adición de una réplica con nombre en un grupo elástico de Hiperescala. Al intentar agregar una réplica con nombre de una base de datos de Hiperescala a un grupo elástico de Hiperescala, se produce un error UnsupportedReplicationOperation. En su lugar, cree la réplica con nombre como una base de datos única de Hiperescala.

Consideraciones sobre grupos elásticos con redundancia de zona

Estas son algunas consideraciones para los grupos elásticos de Hiperescala con redundancia de zona:

  • Solo se pueden agregar bases de datos con redundancia de almacenamiento con redundancia de zona (ZRS o GZRS) a grupos elásticos de Hiperescala con redundancia de zona.
  • Se debe crear una base de datos de Hiperescala independiente con redundancia de zona y almacenamiento de copia de seguridad con redundancia de zona (ZRS o GZRS) para agregarla a un grupo elástico de Hiperescala con redundancia de zona. En el caso de las bases de datos de Hiperescala sin redundancia de zona, realice una transferencia de datos a una nueva base de datos de Hiperescala con la opción de redundancia de zona habilitada. Se debe crear un clon mediante la copia de base de datos, la restauración a un momento dado o la réplica geográfica. Para más información, consulte Reimplementación (Hiperescala).
  • Para mover una base de datos de Hiperescala de un grupo elástico a otro, la redundancia de zona y la configuración de almacenamiento de copia de seguridad con redundancia de zona deben coincidir.
  • Para convertir una base de datos desde otro nivel de servicio que no es de Hiperescala a un grupo elástico de Hiperescala con redundancia de zona:
    • A través de Azure Portal, habilite primero la redundancia de zona y el almacenamiento de copia de seguridad con redundancia de zona (ZRS). A continuación, puede agregar la base de datos al grupo elástico de Hiperescala con redundancia de zona.
    • A través de PowerShell, habilite primero la redundancia de zona. A continuación, con Set-AzSqlDatabase, asegúrese de que el parámetro -BackupStorageRedundancy se usa para especificar el almacenamiento de copia de seguridad con redundancia de zona (ZRS o GZRS).

Problemas conocidos

Problema Recomendación
La adición de una base de datos de un grupo elástico de Hiperescala redundante de zona, a un grupo de migración tras error con un grupo elástico de Hiperescala no redundante de zona en otra región, fallará internamente, pero la operación puede parecer que se está ejecutando sin ningún progreso. Es posible que vea la base de datos secundaria geográfica al usar herramientas como SSMS, pero no puede conectarse a la base de datos secundaria geográfica y usarla. El grupo de migración tras error puede mostrar un estado de "Propagación del 0 %" para la base de datos secundaria geográfica. Este problema no se produce si el segundo grupo elástico de Hiperescala tiene redundancia de zona. Para solucionar este problema, configure la replicación geográfica fuera del grupo de migración tras error mediante Azure PowerShell y especifique explícitamente redundancia de zona en la línea de comandos New-AzSqlDatabaseSecondary -ResourceGroupName "primary-rg" -ServerName "primary-server" -DatabaseName "hsdb1" -PartnerResourceGroupName "secondary-rg" -PartnerServerName "secondary-server" -AllowConnections "All" -SecondaryElasticPoolName "secondary-nonzr-pool" -BackupStorageRedundancy Local -ZoneRedundant:$false. A continuación, puede agregar la base de datos de ejemplo al grupo de migración tras error.
En raras ocasiones, es posible que reciba el error 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support al intentar mover, restaurar o copiar una base de datos de Hiperescala en un grupo elástico. Esta limitación se debe a detalles específicos de la implementación. Si este error le bloquea, genere un incidente de soporte técnico y solicite ayuda.

Contenido relacionado