In the last post, we have discussed the DTU purchase model. Azure also provides another purchase mode which is called vCore. vCore purchase model available with all three deployment models (Managed instance, Single database, and elastic pool).
vCore purchase model provides :
- Higher compute, memory, IO, and storage limit.
- Better control over opting for the hardware configuration.
- Option to bring your own license using the Azure Hybrid Benefit(AHB) and to reserve the instance to reduce the cost.
- Flexibility to choose the compute and storage independently.
- Storage and compute charged separately. In the DTU model ,limited amount od storage bundled with the computing power. Storage allocated above that is charged separately.
Service Tier: Like in the DTU model, the vCore model also provides multiple service tier to match with your performance requirements and budget. vCore purchase model provides the following service tiers.
- General Purpose
- Hyper-Scale
- Business Critical
General Purpose :
- Offer Budget-oriented, balanced and scalable compute and storage option.
- Suited for general workload.
- Available with all three deployment model (Single, elastic and managed)
- Option to select 2 to 80 vCore. The options are 2 ,4 ,6 ,8 ,10,12,14,16,18, 20,24,32,40 and 80 vCore
- Storage upto 4 TB (0.12 USD per GB).
- Remote storage
- 500 to 20000 IOPS
- 2 to 10 ms latency
- For high availability, it provides one replica.
- No read replica.
- 7 to 35 Backup retention
Hyperscale :
- Available only for single database deployment model
- Provide highly scalable storage up to 100TB
- For rapid read scale-out deployment, provide up to 4 read replica
- Read replicas are charged.
- Option to select compute power from 2 to 80 vCore (options are the same as in general-purpose)
- Use local SSD storage.
- Snapshot based backup in Azure remote storage. Restore use these snapshots for fast recovery.
- Backup/restore does not depend on the size of the database and does not affect the IO or compute as it is performed using the snapshot. Hence backup and restorations are instantaneous.
- For example. 50 TB database can be restored in less than 15 minutes. You can watch the video here
- Depending on the workloads, IOPS between 500 to 204800 with 1 to 10 ms latency.
- Most suited for databases that will not fit into the 4TB storage limit of general-purpose and business-critical service tier.
- Hyperscale database engines use distributed function architecture and use the following components (we will discuss the architecture of hyper-scale in a different blog post). This architecture is different from the existing database engine architecture
- Compute
- Page Server
- Log Service
- Aure storage
Business Critical :
- Available with all three deployment model (Single, elastic and managed)
- Option to select 2 to 80 vCore. The options are 2 ,4 ,6 ,8 ,10,12,14,16,18, 20,24,32,40 and 80 vCore
- Offers business applications the highest resilience to failures by using several isolated replicas.
- It keeps 4 replicas for better high availability
- To offload the read workload from the writable replica, provide read replica without additional charge.
- Use local SSD storage for better IO performance.
- Provides up to 4 TB storage with 1 -2 ms latency (0.25 USD per GB)
- 5000 to 204800 IOPS
- 7 to 35 days backup retention.
Compute Tier: Under the service tier, azure SQL server provides the compute tier. For managed instance and elastic pool deployment models, azure provides only provisioned compute tier and this option will not be available to choose. For the single database deployment, there is one more additional compute tier called Serverless. Let us see the difference between these two compute tier:
Provisioned :
- compute tier is provisioned through out the lifecycle of elastic poo/ single database/managed instance and billed hourly basis.
- There is no change in the billing based on the workload on the database.
- Suitable for regular usage patterns with higher average compute utilization over time.
- Compute scaling should be done manually (increasing the vCore)
Serverless :
- Suitable for Intermittent, unpredictable usage with lower average compute utilization over time.
- Automatically scale up the compute based on the workload and billed per second.
- Automatically pause the database if there is no activity for a preconfigured time (Auto pause delay) and start automatically when the wake-up events happen. During this period compute is not charged.
- While provisioning, we need to define the minimum and maximum vCore.
- Based on the workload, the compute tier is scaled up to the max vCore defined. Compute is billed per second.
- Auto pause delay is a configurable parameter that defines the required inactive period before pausing the database. This can vary from 1 hour to 7 days. For example, if we define the auto-pause delay as 2 hrs, then if there is no activity in the database for 2 hours, then the database will go to pause state and will not be charged for computing until the next wake up event. Till that point, only the storage cost will be charged.
- The minimum and maximum vCore are configurable parameters that define the range of computing power available for the database. The maximum vCore can vary between 1 to 16 vCore. (1,2,4,6,8.1,10,12,14 and 16 are possible options) . The minimum vCore can vary from 0.5 vCPU to maximum vCore configured. Each vCpu provides 3GB of memory. If the workload requires memory more than that will be charged.
- Cost
- Compute cost and storage costs are charged separately. Storage cost remains the same throughout the life cycle unless you scale up the storage.
- When the compute usage is between the min vCore and max vCore configured, compute cost is based on vCore or memory.
- When the compute usage is below the min vCore setting, it will be still charged for min vCpu/ Memory.
- For the duration of the paused state, Computing is not charged. Only storage will be charged.
- Auto pause and auto-scaling
- When the database is in a paused state, the first wake up event (example connection request) fails with the error message "database is unavailable" with error code 40613. It will take approximately one minute to resume the operation. Applications that are working with a serverless database should have mechanisms to handle this error message and retry the connection after a minute.
- When the load on the database increases, azure automatically scales up the compute / memory up to the max vCore configured. while scaling up the compute, at the end of the process all connections to the database are dropped. The applications which use the serverless database should have a mechanism to handle these error and try to reconnect after a specific time to provide smooth user experience to the end-users.
- Billing
- Use per second billing.
- Each vCore in action provides 3GB memory. If the workload uses more memory than the memory bundled with the vCore, billing will be based on the memory. For example, for a specific time interval, the load on the database is using 2 vCore and 10 GB memory. In this case, billing will be based on the memory as the memory utilization is above 6 GB (2vCore*3 GB). To derive the number vCore to be billed from the memory utilization, memory utilized will be divided by 3 (3GB for each Vcore). In our case, it will be billed for 10GB/3 = 3.33 vCore. The below table gives you a better understanding of the billing. Let us consider one database, that is provisioned with 3 vCore as minimum vCore and 16 as maximum vCore.The auto pause delay is configured as 2 hrs. Each vCore seconds is charged at 0.000145
The total vCore seconds are 389952 and it will cost 56.54 USD (0.000145 USD * 389952 vCore seconds) for the workload mentioned in the above table which spread across 24hrs.
- Best suited for :
- Single database with intermittent and unpredictable usage patterns.
- The database workload is only during specific intervals. So after the auto-pause delay, the database enters into stop state and not charged for the compute.
- Workload is not sensitive to the response time and the application is capable fo handling the errors while resuming the service and auto-scaling
Apart from connecting to the database, there are many other events that resume the database from a paused state. You can find those events in the Azure documentation page
Hardware Configuration Azure provides multiple hardware options to choose from under the service tier. These options differ from region to region. Commonly available hardware options are
- Gen4
- Provide 7 GB memory for each vCore.
- Approaching the end of life by Jan 2023
- Gen5
- Has new generation hardware
- Has network acceleration and provide better IO performance on remote storage (General purpose service tier)
- It uses faster local SSD disk than Gen4
- M-Series (preview)
- New Memory-optimized hardware
- Provide 29GB per vCore.
- It provides up to 128 vCore.
- In full capacity memory can be nearly 4 TB (128 vCore X 29 GB per vCore).
- Fsv2-series (Preview)
- Compute-optimized hardware.
- Low CPU latency and high clock speed for the most CPU demanding workloads.
- Can deliver more CPU performance per vCore than Gen5.
- The 72 vCore size can also provide more CPU performance for less cost than 80 vCores on Gen5.
- provides less memory and tempdb size per vCore than other hardware. so workloads sensitive to those limits may want to consider Gen5 or M-series.
The below diagram provides you a visual representation of vCore purchase model options for Single database and Elastic pool.
 |
| vCore Purchase Model |
Managed Instance deployment model also provides General Purpose and Business Critical service tier. Under the service tier, it provides Gen4 and Gen5 hardware.
Each combination of these options has many other characteristics like tempdb space allocated, log space allocated, IOPS, no of concurrent session, log write throughput, etc. All those detailed information can be found in the following Azure documentation.
I hope, this post helped you understand the vCore purchase mode in detail.
