Información general del modelo de compra de núcleo virtual: Azure SQL Database y Azure SQL Managed Instance

Se aplica a: Azure SQL Database Azure SQL Managed Instance

En este artículo se proporciona una breve descripción general del modelo de compra de núcleo virtual que usan Azure SQL Database y Azure SQL Managed Instance. Para obtener más información sobre el modelo de núcleo virtuale para cada producto, revise Azure SQL Database y Azure SQL Managed Instance.

Información general

Un núcleo virtual representa la CPU lógica y ofrece una opción para elegir las características físicas de hardware (por ejemplo, el número de núcleos, la memoria y el tamaño de almacenamiento). El modelo de compra basado en núcleo virtual le ofrece flexibilidad, control, transparencia de consumo de recursos individuales y una manera sencilla de trasladar los requisitos de carga de trabajo locales a la nube. Este modelo optimiza el precio y le permite elegir los recursos de proceso, memoria y almacenamiento en función de las necesidades de la carga de trabajo.

En el modelo de compra basado en núcleo virtual, los costos dependen de la elección y el uso de:

  • Nivel de servicio
  • Configuración de hardware
  • Los recursos de proceso (número de núcleos virtuales y cantidad de memoria)
  • Almacenamiento reservado de la base de datos
  • Almacenamiento de copia de seguridad real

Importante

En Azure SQL Database, los recursos de proceso (CPU y memoria), las tareas de E/S y el almacenamiento de datos y registros se cobran en función de cada base de datos o grupo elástico. El almacenamiento de copia de seguridad se cobra por cada base de datos.

El modelo de compra de núcleo virtual proporciona transparencia con respecto a la asignación de los recursos de almacenamiento, la memoria y la CPU de las bases de datos. Además, también ofrece opciones de configuración de hardware, una mayor granularidad de escalado y descuentos en los precios gracias a la Ventaja híbrida de Azure (AHB) y a las instancias reservadas (RI).

En el caso de Azure SQL Database, el modelo de compra de núcleo virtual proporciona mayores límites de proceso, memoria, E/S y almacenamiento que el modelo DTU.

Niveles de servicio

Hay dos niveles de servicio de núcleo virtual disponibles en Azure SQL Database y en Azure SQL Managed Instance:

  • El nivel De uso general es un nivel económico diseñado para la mayoría de las cargas de trabajo con requisitos comunes de rendimiento y disponibilidad.
  • El nivel Crítico para la empresa está diseñado para las cargas de trabajo sensibles al rendimiento con requisitos estrictos de disponibilidad.

El nivel de servicio Hiperescala también está disponible para bases de datos únicas en Azure SQL Database. Este nivel de servicio está diseñado para la mayoría de las cargas de trabajo empresariales; proporciona almacenamiento altamente escalable, escalado horizontal de lectura, escalado rápido y funcionalidades rápidas de restauración de las bases de datos.

Límites de recursos

Para más información sobre los límites de recursos, vea lo siguiente:

Costo del proceso

El modelo de compra basado en núcleo virtual tiene un nivel de proceso aprovisionado para Azure SQL Database y Azure SQL Managed Instance, y un nivel de proceso sin servidor para Azure SQL Database.

En el nivel de proceso aprovisionado, el costo de proceso refleja la capacidad total de proceso aprovisionada continuamente para la aplicación, independientemente de la actividad de carga de trabajo. Elija la asignación de recursos que mejor se adapte a sus necesidades empresariales en función de los requisitos de memoria y núcleo virtual y, a continuación, aumente o reduzca los recursos según precise la carga de trabajo.

En el nivel de proceso sin servidor para la base de datos de Azure SQL, los recursos de proceso se escalan automáticamente en función de la capacidad de carga de trabajo y se facturan por la cantidad de proceso usado, por segundo.

Puesto que se asignan tres réplicas adicionales de manera automática en el nivel de servicio Crítico para la empresa, el precio es aproximadamente 2,7 veces mayor que en el nivel de servicio De uso general. De igual modo, el mayor precio de almacenamiento por GB en el nivel de servicio Crítico para la empresa refleja que el almacenamiento en SSD local tiene unos límites de E/S superiores y una latencia menor.

Almacenamiento de datos y de registro

Los factores siguientes afectan a la cantidad de almacenamiento utilizado para los datos y los archivos de registro, y se aplican a los niveles De uso general y Crítico para la empresa.

  • Cada tamaño de proceso admite un tamaño máximo de datos configurable con un valor predeterminado de 32 GB.
  • Al configurar el tamaño máximo de datos, se agrega automáticamente un 30 por ciento adicional de almacenamiento facturable para el archivo de registro.
  • En el nivel de servicio De uso general, tempdb usa el almacenamiento local de SSD y este costo de almacenamiento se incluye en el precio del núcleo virtual.
  • En el nivel de servicio Crítico para la empresa, tempdb comparte el almacenamiento local de SSD con datos y archivos de registro, y el costo de almacenamiento tempdb se incluye en el precio del núcleo virtual.
  • En los niveles De uso general y Crítico para la empresa, se le cobra por el tamaño máximo de almacenamiento que tiene configurado para una base de datos, un grupo elástico o una instancia administrada.
  • Para SQL Database, puede seleccionar cualquier tamaño máximo de datos entre 1 GB y el tamaño de almacenamiento máximo admitido, en incrementos de 1 GB. Para Azure SQL Managed Instance, seleccione tamaños de datos en múltiples de 32 GB hasta el tamaño máximo de almacenamiento admitido.

Si desea supervisar el tamaño actual del almacenamiento de datos asignados y utilizados en SQL Database, use las métricasallocated_data_storage y storage de Azure Monitor, respectivamente.

Tanto para SQL Database como SQL Managed Instance, si desea supervisar el tamaño actual del almacenamiento asignado y utilizado de datos y archivos de registro individuales en una base de datos con T-SQL, utilice la vista sys.database_files y la función FILEPROPERTY(... , 'SpaceUsed').

Sugerencia

En algunas circunstancias, puede que deba reducir una base de datos para reclamar el espacio no utilizado. Para obtener más información, consulte Administración del espacio de archivo en Azure SQL Database.

Almacenamiento de copia de seguridad

Para admitir las funcionalidades de restauración a un momento dado (PITR) y retención a largo plazo (LTR) de SQL Database y SQL Managed Instance, se asigna almacenamiento a las copias de seguridad de base de datos. Este almacenamiento es independiente del almacenamiento de datos y archivos de registro, y se factura por separado.

  • PITR: En los niveles De uso general y Crítico para la empresa, las copias de seguridad de base de datos individuales se copian en Azure Storage automáticamente. El tamaño de almacenamiento aumenta dinámicamente a medida que se crean nuevas copias de seguridad. El almacenamiento se utiliza para copias de seguridad completas, diferenciales y del registro de transacciones. El consumo de almacenamiento depende de la tasa de cambio de la base de datos y del período de retención configurado para las copias de seguridad. Puede configurar un período de retención independiente para cada base de datos de entre 1 y 35 días para SQL Database y de entre 0 a 35 días para SQL Managed Instance. Se proporciona una cantidad de almacenamiento de copia de seguridad equivalente al tamaño máximo de datos configurado sin costo adicional.
  • LTR: también tiene la opción de configurar la retención a largo plazo de copias de seguridad completas hasta un máximo de 10 años. Si ha instalado la directiva de LTR, estas copias de seguridad se almacenan en Azure Blob Storage automáticamente, pero puede controlar la frecuencia con que se realizan las copias de seguridad. Para satisfacer los distintos requisitos de cumplimiento, puede seleccionar distintos períodos de retención para copias de seguridad semanales, mensuales o anuales. La configuración que elija determina la cantidad de almacenamiento que se usará para las copias de seguridad de LTR. Para obtener más información, vea Retención de copias de seguridad a largo plazo.

Pasos siguientes

Para empezar, consulte:

Para obtener más información sobre los tamaños específicos de proceso y almacenamiento disponibles en los niveles de servicio De uso general y Crítico para la empresa, consulte: