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

  • Artículo

Se aplica a:Azure SQL Database

Este artículo ofrece información general de 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.

Nota:

Los grupos elásticos de Hiperescala están actualmente en versión preliminar.

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 migración de bases de datos que no son de Hiperescala a un grupo elástico de Hiperescala actualiza las bases de datos en el nivel de servicio de Hiperescala.

Architecture

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:

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

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

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

Migració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 migrar 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 migració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 migrar 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 migración. En el ejemplo que se muestra, tendría cuatro migraciones 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 migración en segundo plano.

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

Puede utilizar comandos de PowerShell para migrar 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 migración. En este caso, va a solicitar implícitamente una migració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 migraciones 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 migració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.

Nota:

Los perfiles de rendimiento, las funcionalidades admitidas y los límites publicados están sujetos a cambios mientras la característica está en versión preliminar. Por lo tanto, es mejor validar el caso de uso con pruebas regulares funcionales, de rendimiento y de escalado de las cargas de trabajo.

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 migració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

En el caso de los grupos elásticos con redundancia de zona, tenga en cuenta lo siguiente:

Nota:

Los grupos elásticos de Hiperescala con redundancia de zonas están disponibles, actualmente en fase de vista previa. Para más información, consulte Entrada de blog: 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 migrar 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
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