Modelo de compra de núcleo virtual: Azure SQL Database

Se aplica a: Azure SQL Database

En este artículo se revisa el modelo de compra de núcleo virtual para Azure SQL Database.

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

Comparación de modelos de compra de núcleo virtual y DTU

El modelo de compra de núcleo virtual que usa Azure SQL Database proporciona varias ventajas con respecto al modelo de compra basado en DTU:

• Mayores límites de proceso, memoria, E/S y almacenamiento.
• Elección de la configuración de hardware para satisfacer mejor los requisitos de proceso y memoria de la carga de trabajo.
• Descuentos de precios para Ventaja híbrida de Azure (AHB).
• Mayor transparencia en los detalles de hardware que potencian el proceso, lo que facilita la planeación de las migraciones desde implementaciones locales.
• Los precios de las instancias reservadas solo están disponibles para el modelo de compra de núcleo virtual.
• Mayor granularidad de escalado con varios tamaños de proceso disponibles.

Para elegir entre los modelos de compra de núcleo virtual y DTU, vea las diferencias entre los modelos de compra basados en DTU y núcleo virtual.

Compute

El modelo de compra basado en núcleo virtual tiene un nivel de proceso aprovisionado y otro sin servidor. 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 Azure SQL Database, 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.

En resumen:

• Mientras que el nivel de proceso aprovisionado proporciona una cantidad específica de recursos de proceso que se aprovisionan continuamente independientemente de la actividad de la carga de trabajo, el nivel de cálculo sin servidor escala automáticamente los recursos de proceso en función de la actividad de carga de trabajo.
• Mientras que el nivel de proceso aprovisionado se factura para la cantidad de proceso aprovisionada a un precio fijo por hora, el nivel de proceso sin servidor se factura para la cantidad de proceso usada por segundo.

Independientemente del nivel de proceso, se asignan automáticamente tres réplicas secundarias de alta disponibilidad adicionales en el nivel de servicio Crítico para la empresa a fin de proporcionar alta resistencia a errores y conmutaciones por error rápidas. Estas réplicas adicionales hace que el costo sea aproximadamente 2,7 veces mayor que en el nivel de servicio De uso general. De igual modo, el costo más alto de almacenamiento por GB en el nivel de servicio Crítico para la empresa refleja que el almacenamiento SSD local tiene unos límites de E/S superiores y una latencia menor.

En Hiperescala, los clientes controlan el número de réplicas de alta disponibilidad adicionales de 0 a 4 para obtener el nivel de resistencia que requieren sus aplicaciones mientras controlan los costos.

Para obtener más información de proceso en Azure SQL Database, consulte Recursos de proceso (CPU y memoria).

Límites de recursos

Para ver los límites de recursos de núcleo virtual, revise las configuraciones de hardware disponibles y los límites de recursos para:

• servidores lógicos
• bases de datos únicas
• bases de datos en grupos elásticos

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 o un grupo elástico.
• 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.

Las consideraciones sobre el almacenamiento siguientes se aplican a Hiperescala:

• El tamaño máximo de almacenamiento de datos se establece en 128 TB y no se puede configurar.
• Solo se le cobra por el almacenamiento de datos asignado, no por el almacenamiento de datos máximo.
• No se le cobrará por el almacenamiento de registros.
• tempdb usa el almacenamiento local de SSD y su costo se incluye en el precio del núcleo virtual. 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.

Para 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').

Almacenamiento de copia de seguridad

Para admitir las capacidades de restauración a un momento dado y retención a largo plazo (LTR) de SQL Database, 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 diferente para cada base de datos de entre 1 y 35 días en SQL Database. 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 puede configurar la retención a largo plazo de copias de seguridad completas durante 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 usa para las copias de seguridad de LTR. Para obtener más información, vea Retención de copias de seguridad a largo plazo.

Para el almacenamiento de copia de seguridad en Hiperescala, vea Copias de seguridad automatizadas para bases de datos de Hiperescala.

Niveles de servicio

Entre las opciones de nivel de servicio del modelo de compra de núcleo virtual se incluyen Uso general, Crítico para la empresa e Hiperescala. El nivel de servicio normalmente determina el tipo de almacenamiento y el rendimiento, las opciones de alta disponibilidad y recuperación ante desastres, y la disponibilidad de determinadas características, como OLTP en memoria.

¹ Precios simplificados de Hiperescala de SQL Database próximamente. Revise el blog de precios de Hiperescala para más información.

Para obtener más información, revise los límites de recursos para servidores lógicos, bases de datos únicas y bases de datos agrupadas.

De uso general

El modelo de arquitectura para el nivel de servicio de uso general se basa en la separación del proceso y el almacenamiento. Este modelo de arquitectura se basa en la alta disponibilidad y fiabilidad de Azure Blob Storage que replica de forma transparente los archivos de base de datos y garantiza que no se pierdan los datos si se produce algún error en la infraestructura subyacente.

En la siguiente imagen se muestran cuatro nodos en el modelo de arquitectura estándar con las capas separadas de proceso y almacenamiento.

En el modelo de arquitectura para el nivel de servicio de uso general, hay dos capas:

• Una capa de proceso sin estado que ejecuta el proceso sqlservr.exe y que solo contiene datos en caché y transitorios (por ejemplo, caché de planes, grupo de búferes o grupo de almacenes de columnas). Este nodo sin estado lo opera Azure Service Fabric, que inicializa el proceso, controla el estado del nodo y realiza la conmutación por error en otro lugar si es necesario.
• Una capa de datos con estado con archivos de base de datos (.mdf o .ldf) que se almacenan en Azure Blob Storage. Azure Blob Storage garantiza que no se pierdan los datos de ningún registro que se encuentre en un archivo de base de datos. Azure Storage tiene redundancia o disponibilidad de datos integrada que garantiza la conservación de los registros de una página o archivo de registro aunque se bloquee el proceso.

Siempre que se actualice un sistema operativo o un motor de base de datos, si se produce un error en la infraestructura subyacente, o si se detecta algún problema crítico en el proceso sqlservr.exe, Azure Service Fabric mueve el proceso sin estado a otro nodo de proceso sin estado. Hay un conjunto de nodos libres que esperan ejecutar un nuevo servicio de proceso si se produce una conmutación por error del nodo principal, a fin de minimizar el tiempo de conmutación por error. Esto no afecta a los datos de la capa de Azure Storage, y los archivos de registro o de datos se anexan al proceso inicializado recientemente. Este proceso garantiza una disponibilidad del 99,99 % de forma predeterminada y una disponibilidad del 99,995 % cuando está habilitada la redundancia de zona. Podría afectar al rendimiento de grandes cargas de trabajo que están en proceso debido al tiempo de transición y al hecho de que el nuevo nodo se inicia con la caché inactiva.

¿Cuándo elegir este nivel de servicio?

De uso general es un nivel de servicio predeterminado de Azure SQL Database diseñado para la mayoría de las cargas de trabajo genéricas. Si necesita un motor de base de datos totalmente administrado con un contrato de nivel de servicio predeterminado y una latencia de almacenamiento de entre 5 y 10 ms, el nivel De uso general es la opción que busca.

Crítico para la empresa

El modelo de nivel de servicio Crítico para la empresa se basa en un clúster de procesos del motor de base de datos. Este modelo de arquitectura se basa en un cuórum de nodos de motor de base de datos para minimizar los impactos en el rendimiento de su carga de trabajo, incluso durante las actividades de mantenimiento. Las actualizaciones y revisiones del sistema operativo subyacente, los controladores y el motor de base de datos se producen de forma transparente, con el mínimo tiempo de inactividad para los usuarios finales.

En el modelo Crítico para la empresa, el proceso y el almacenamiento se integran en cada nodo. La alta disponibilidad se logra mediante la replicación de datos entre procesos del motor de base de datos en cada nodo de un clúster de cuatro nodos, en el que cada nodo usa un SSD conectado localmente como almacenamiento de datos. En el diagrama siguiente se muestra cómo el nivel de servicio Crítico para la empresa organiza un clúster de nodos del motor de base de datos en las réplicas del grupo de disponibilidad.

El proceso del motor de base de datos y los archivos .mdf o .ldf subyacentes se colocan en el mismo nodo con el almacenamiento SSD conectado localmente, lo que proporciona baja latencia para la carga de trabajo. La alta disponibilidad se implementa mediante tecnología parecida a la de los grupos de disponibilidad AlwaysOn de SQL Server. Cada base de datos es un clúster de nodos de base de datos con una réplica principal, a la que se puede acceder para las cargas de trabajo de cliente, y a tres réplicas secundarias que contienen copias de los datos. La réplica principal inserta constantemente los cambios a las réplicas secundarias para garantizar que los datos estén disponibles en réplicas secundarias si, por cualquier motivo, se produce un error en la principal. Service Fabric y el motor de base de datos controlan la conmutación por error: una réplica secundaria se convierte en la principal y se crea una réplica secundaria para garantizar que hay suficientes nodos en el clúster. La carga de trabajo se redirige automáticamente a la nueva réplica principal.

Además, el clúster Crítico para la empresa tiene una capacidad Escalado horizontal de lectura integrada, que proporciona una réplica de solo lectura gratuita usada para ejecutar consultas de solo lectura (por ejemplo, informes) que no afectarán al rendimiento de la carga de trabajo en la réplica principal.

¿Cuándo elegir este nivel de servicio?

El nivel de servicio Crítico para la empresa está diseñado para las aplicaciones que requieren respuestas de baja latencia desde el almacenamiento SSD subyacente (1 o 2 ms como promedio), recuperación más rápida si se produce un error en la infraestructura subyacente o necesidad de descargar informes, análisis y consultas de solo lectura en la versión gratuita de la réplica secundaria legible de la base de datos principal.

A continuación, se indican las principales razones por las que debe elegir el nivel de servicio Crítico para la empresa en lugar del nivel De uso general:

• Requisitos de baja latencia de E/S: las cargas de trabajo que necesitan sistemáticamente una respuesta rápida de la capa de almacenamiento (promedio de 1 a 2 milisegundos) deben usar el nivel Crítico para la empresa.
• Carga de trabajo con informes y consultas analíticas donde basta con una única réplica secundaria gratuita de solo lectura.
• Mayor resistencia y recuperación más rápida de los errores. En caso de error del sistema, se deshabilitará la base de datos en la instancia principal y una de las réplicas secundarias se convertirá inmediatamente en la nueva base de datos principal de lectura y escritura, lista para procesar las consultas.
• Protección avanzada de datos dañados. Dado que el nivel Crítico para la empresa usa réplicas de bases de datos en segundo plano, el servicio usa la reparación automática de páginas que hay disponible con la creación de reflejo y los grupos de disponibilidad para ayudar a mitigar los datos dañados. Si una réplica no puede leer una página debido a un problema de integridad de datos, se recuperará una copia nueva de la página de otra réplica, lo que reemplazará la página ilegible sin que se produzca pérdida de datos ni tiempo de inactividad del cliente. Esta función está disponible en el nivel De uso general si la base de datos tiene una réplica geográfica secundaria.
• Mayor disponibilidad: el nivel Crítico para la empresa en la configuración de varias zonas de disponibilidad proporciona resistencia a errores de zona y un Acuerdo de Nivel de Servicio de mayor disponibilidad.
• Recuperación geográfica rápida: cuando se configura la replicación geográfica activa, el nivel Crítico para la empresa tiene un Objetivo de punto de recuperación (RPO) garantizado de 5 segundos y un Objetivo de tiempo de recuperación (RTO) de 30 segundos durante el 100 % de las horas implementadas.

Hiperescala

El nivel de servicio Hiperescala es adecuado para todos los tipos de carga de trabajo. Su arquitectura nativa en la nube proporciona proceso y almacenamiento escalables de forma independiente para admitir la mayor variedad de aplicaciones tradicionales y modernas. Los recursos de proceso y almacenamiento en Hiperescala superan considerablemente los disponibles en los niveles De uso general y Crítico para la empresa.

Para obtener más información, revise Nivel de servicio Hiperescala para Azure SQL Database.

¿Cuándo elegir este nivel de servicio?

El nivel de servicio Hiperescala elimina muchos de los límites prácticos que tradicionalmente se ven en las bases de datos en la nube. Donde la mayoría de las otras bases de datos están limitados por los recursos disponibles en un único nodo, las bases de datos en el nivel de servicio Hiperescala no tienen límites de este tipo. Con su arquitectura de almacenamiento flexible, una base de datos de Hiperescala crece según sea necesario y solo se le factura por la capacidad de almacenamiento que usa.

Además de sus capacidades avanzadas de escalado, Hiperescala es una opción excelente para cualquier carga de trabajo, no solo para bases de datos de gran tamaño. Gracias a Hiperescala, podrá realizar lo siguiente:

• Lograr una alta resistencia y recuperación rápida de errores a la vez que se controla el costo, al elegir el número de réplicas de alta disponibilidad de 0 a 4.
• Mejorar la alta disponibilidad habilitando la redundancia de zona para el proceso y el almacenamiento.
• Lograr una baja latencia de E/S (de 1 a 2 milisegundos de media) para la parte de la base de datos a la que se accede con frecuencia. Para bases de datos más pequeñas, esto puede aplicarse a toda la base de datos.
• Implementar una gran variedad de escenarios de escalado horizontal de lectura con réplicas con nombre.
• Sacar partido del escalado rápido, sin necesidad de esperar a que los datos se copien en el almacenamiento local en nuevos nodos.
• Disfrutar de la copia de seguridad continua de la base de datos con impacto cero y la restauración rápida.
• Disponer de compatibilidad con los requisitos de continuidad empresarial mediante grupos de conmutación por error y replicación geográfica.

Configuración de hardware

Las configuraciones de hardware del modelo de núcleo virtual incluyen la serie estándar (Gen5), la serie Fsv2 y la serie DC. Hiperescala también proporciona una opción para la serie premium y para el hardware optimizado para memoria de la serie premium. La configuración de hardware define los límites de proceso y memoria y otras características que afectan el rendimiento de la carga de trabajo.

Algunas configuraciones de hardware, como la serie estándar (Gen5), pueden usar más de un tipo de procesador (CPU), como se describe en Recursos de proceso (CPU y memoria). Aunque una base de datos o un grupo elástico dados tienden a permanecer en el hardware con el mismo tipo de CPU durante mucho tiempo (normalmente durante varios meses), hay ciertos eventos que pueden hacer que una base de datos o un grupo se muevan a hardware que use un tipo de CPU diferente.

Se puede mover una base de datos o un grupo para una variedad de escenarios, entre los que se incluyen, entre otros:

• El objeto de servicio se cambia
• La infraestructura actual de un centro de datos se está aproximando a los límites de capacidad
• El hardware usado actualmente se va a retirar debido a su fin de vida
• La configuración con redundancia de zona está habilitada; la base de datos o grupo se va a mover a un hardware diferente debido a la capacidad disponible

En algunas cargas de trabajo, un cambio a otro tipo de CPU puede suponer un cambio en el rendimiento. SQL Database configura el hardware con el objetivo de proporcionar un rendimiento predecible de la carga de trabajo incluso si el tipo de CPU cambia, y mantiene los cambios de rendimiento dentro de una banda estrecha. Sin embargo, en el amplio espectro de las cargas de trabajo de clientes en SQL Database, y a medida que haya nuevos tipos de CPU disponibles, es posible que se aprecien ocasionalmente cambios más perceptibles en el rendimiento si una base de datos o un grupo se mueven a otro tipo de CPU.

Independientemente del tipo de CPU que se usa, los límites de recursos de una base de datos o un grupo elástico, como el número de núcleos, la memoria, el número máximo de IOPS de datos, la velocidad máxima de registro y el número máximo de trabajos simultáneos, seguirán siendo los mismos mientras la base de datos permanezca en el mismo objetivo del servicio.

Recursos de proceso (CPU y memoria)

En la tabla siguiente se comparan los recursos de proceso en distintas configuraciones de hardware y niveles de proceso:

* En la vista de administración dinámica sys.dm_user_db_resource_governance, la generación de hardware para bases de datos que usan procesadores Intel® SP-8160 (Skylake) aparece como Gen6, la generación de hardware para bases de datos que usan procesadores Intel® 8272CL (Cascade Lake) aparece como Gen7 y la generación de hardware para bases de datos que usan procesadores Intel® Xeon® Platinum 8370C (Ice Lake) o AMD® EPYC® 7763v (Milan) aparece como Gen8. Para una configuración de hardware y tamaño de proceso determinada, los límites de recursos son los mismos independientemente del tipo de CPU (Intel Broadwell, Skylake, Ice Lake, Cascade Lake o AMD Milan).

Para obtener más información, consulte los límites de recursos de bases de datos únicas y grupos elásticos.

Para conocer la especificación y los recursos de proceso de la base de datos de Hiperescala, consulte Recursos de proceso de Hiperescala.

Serie estándar (Gen5)

• El hardware de la serie estándar (Gen5) proporciona recursos de proceso y memoria equilibrados, y es adecuado para la mayoría de las cargas de trabajo de base de datos.

El hardware de la serie estándar (Gen5) está disponible en todas las regiones públicas de todo el mundo.

Serie premium de Hiperescala

• Las opciones de hardware de la serie prémium usan las CPU y tecnologías de memoria más recientes de Intel y AMD. La serie premium proporciona un aumento del rendimiento de proceso en relación con el hardware de la serie estándar.
• La opción de la serie premium ofrece un rendimiento de CPU más rápido en comparación con la serie estándar, y un mayor número de núcleos virtuales máximos.
• La opción optimizada para memoria de la serie premium ofrece el doble de memoria relativa a la serie estándar.
• La serie estándar, la serie Premium y la memoria optimizada para la serie Premium están disponibles para grupos elásticos de Hiperescala.

Para más información, consulte el anuncio del blog de la serie premium de Hiperescala.

Para ver las regiones disponibles, consulte Disponibilidad de la serie Premium de Hiperescala.

Serie Fsv2

• La serie Fsv2 es una configuración de hardware optimizado para proceso que ofrece una latencia de CPU baja y una velocidad de reloj elevada para las cargas de trabajo más exigentes de CPU. De forma similar a las configuraciones de hardware de la serie Premium de Hiperescala, la serie Fsv2 cuenta con la tecnología más reciente de CPU y memoria de Intel y AMD, lo que permite a los clientes aprovechar el hardware más reciente al usar bases de datos y grupos elásticos en el nivel de servicio De uso general.
• En función de la carga de trabajo, la serie Fsv2 puede ofrecer más rendimiento de CPU por núcleo virtual que otros tipos de hardware. Por ejemplo, el tamaño de proceso de Fsv2 de 72 núcleos virtuales puede proporcionar más rendimiento de CPU que 80 núcleos virtuales en la serie estándar (Gen5), a un costo menor.
• Fsv2 proporciona menos memoria y tempdb por núcleo virtual que otro hardware, por lo que las cargas de trabajo sensibles a esos límites pueden ofrecer un mejor rendimiento en la serie estándar (Gen5).

La serie Fsv2 solo se admite en el nivel De uso general. Para las regiones en las que está disponible la serie Fsv2, consulte la disponibilidad de la serie Fsv2.

Serie DC

• El hardware de la serie DC utiliza procesadores Intel con tecnología Software Guard Extensions (Intel SGX).
• La serie DC es necesaria para cargas de trabajo de Always Encrypted de enclaves seguros que requieren una mayor protección de seguridad de los enclaves de hardware, en comparación con los enclaves de seguridad basada en virtualización (VBS).
• La serie DC está diseñada para cargas de trabajo que procesan datos confidenciales y requieren funcionalidades de procesamiento de consultas confidenciales, proporcionadas por Always Encrypted con enclaves seguros.
• El hardware de la serie DC proporciona recursos de proceso y memoria equilibrados.

La serie DC solo es compatible con el proceso aprovisionado (no se admite sin servidor) y no admite la redundancia de zona. Para ver las regiones en las que la serie DC está disponible, consulte la disponibilidad de la serie DC.

Tipos de oferta de Azure disponibles en la serie DC

Para crear bases de datos o grupos elásticos en hardware de la serie DC, la suscripción debe ser un tipo de oferta de pago, como Pago por uso o Contrato Enterprise (EA). Para ver una lista completa de los tipos de oferta de Azure disponibles en la serie DC, consulte las ofertas actuales sin límites de gasto.

Seleccionar configuración de hardware

Puede seleccionar la configuración de hardware de una base de datos o un grupo elástico en SQL Database en el momento de la creación. También puede cambiar la configuración de hardware de una base de datos existente o un grupo elástico.

Seleccionar una configuración de hardware al crear una instancia de SQL Database o un grupo SQL

Para obtener información detallada, consulte Creación de una instancia de SQL Database.

En la pestaña Básico, seleccione el vínculo Configurar base de datos en la sección Compute + storage (Proceso + almacenamiento) y, a continuación, seleccione el vínculo Cambiar configuración:

Seleccione la configuración de hardware deseada:

Cambiar la configuración de hardware de una instancia de SQL Database o un grupo SQL existente

En el caso de una base de datos, en la página de información general, seleccione el vínculo Plan de tarifa:

En la página Información general, seleccione Configurar.

Siga los pasos para cambiar la configuración y seleccione la configuración de hardware como se describe en los pasos anteriores.

Disponibilidad de hardware

Para obtener información sobre las generaciones de hardware anteriores, consulte Disponibilidad de generaciones de hardware anteriores.

Serie estándar (Gen5)

El hardware de la serie estándar (Gen5) está disponible en todas las regiones públicas de todo el mundo.

Serie premium de Hiperescala

El hardware optimizado para memoria de la serie premium y la serie premium del nivel de servicio Hiperescala está disponible para bases de datos únicas y grupos elásticos en las siguientes regiones:

• Este de Australia **
• Sudeste de Australia
• Sur de Brasil **,*
• Centro de Canadá **
• Este de Canadá
• Este de Asia
• Norte de Europa **
• Oeste de Europa **
• Centro de Francia
• Centro-oeste de Alemania
• India central
• Sur de India
• Japón Oriental **
• Japón Occidental
• Sudeste Asiático **
• Norte de Suiza
• Centro de Suecia **,*
• Sur de Reino Unido **
• Oeste de Reino Unido *
• Centro de EE. UU. **
• Este de EE. UU. **
• Este de EE. UU. 2 **
• Centro y norte de EE. UU.
• Centro y Sur de EE. UU.
• Centro-oeste de EE. UU.
• Oeste de EE. UU. 1
• Oeste de EE. UU. 2 **
• Oeste de EE. UU. 3 **

* El hardware optimizado para memoria de la serie Premium no está disponible actualmente.

** Incluye compatibilidad con la redundancia de zona.

Serie Fsv2

La serie Fsv2 está disponible en las siguientes regiones:

• Centro de Australia
• Centro de Australia 2
• Este de Australia
• Sudeste de Australia
• Sur de Brasil
• Centro de Canadá
• Este de Asia
• Norte de Europa
• Oeste de Europa
• Centro de Francia
• India central
• Centro de Corea del Sur
• Corea del Sur
• Norte de Sudáfrica
• Sudeste de Asia
• Sur de Reino Unido
• Oeste de Reino Unido
• Este de EE. UU.
• Oeste de EE. UU. 2

Serie DC

La serie DC está disponible en las siguientes regiones:

• Centro de Canadá
• Oeste de Europa
• Norte de Europa
• Sudeste de Asia
• Sur de Reino Unido
• Oeste de EE. UU.
• Este de EE. UU.

Si necesita la serie DC en una región no admitida actualmente, envíe una solicitud de soporte técnico. En la página Datos básicos, proporcione los valores siguientes:

1. En Tipo de problema, seleccione Técnico.
2. Proporcione la suscripción deseada para el hardware. Seleccione Next (Siguiente).
3. En Tipo de servicio, seleccione Base de datos SQL.
4. En Recurso, seleccione Pregunta general.
5. En Resumen, proporcione la disponibilidad y la región de hardware deseadas.
6. En Tipo de problema, seleccione Seguridad, privacidad y cumplimiento de normas.
7. En Subtipo de problema, seleccione Siempre cifrado.

Hardware de generación anterior

Gen4

El hardware Gen4 ha sido retirado y no está disponible para el aprovisionamiento o el escalado vertical. Migre la base de datos a una generación de hardware compatible para obtener una gama más amplia de escalabilidad de almacenamiento y núcleos virtuales, redes aceleradas, un mejor rendimiento de E/S y una latencia mínima. Revise opciones de hardware para bases de datos únicas y opciones de hardware para grupos elásticos. Para obtener más información, consulte Finaliza la compatibilidad con el hardware de Gen 4 en Azure SQL Database.

Paso siguiente

Contenido relacionado

• Página de precios de Azure SQL Database
• Límites de recursos para bases de datos únicas que utilizan el modelo de compra en núcleos virtuales
• Límites de recursos para grupos elásticos que usan el modelo de compra de núcleo virtual