Problem
Our customer has an issue with their cloud computing expense. They have allocated a VM with over specification with their budget. This is because the VM will work hard in specific time. The customer uses the VM in 09.00 AM and 5 PM. After that the VM is not used.
Requirements
The customer wants you to reduce the cost by downscaling and upscaling the VM based on the time.
Workdays: 09.00 – 17.00 PM
Weekend: Off
//
Solution
You have several solutions to accommodate this.
Turn off the VM outside the workdays and turn of the VM in the workdays (Option A)
Scale down the VM in non-workday, and scale up in the workday (Option B)
Well-Architecture Recommendation
Choosing A, we will get better cost efficiency. However, there is some circumstance when the VM is misbehaving because the cold-start issue.
Choosing B, we still get cost-saving. However, we still pay the downsizing cost
How to do that
We can use many ways to do that. In Azure, you can use Azure Automation. You can read here
Azure Automation Start/Stop VMs during off-hours overview | Microsoft Docs
Azure Automation: Scale-Down VM Size - Microsoft Tech Community
Auto Scale Up and Down VM's with Azure Automation (wordpress.com)
Background
Your customer has a VM (Virtual Machine). The VM contains of Windows Server 2019, SQL Server 2019 Web Edition, and ERP Software. The VM runs on Azure with no redundancy option activated. After a year, the VM has a problem to facilitate the request from the client. Scale up is the first think that we already done. However, the scalability is not fulfilled since one VM means one single point of failure. Therefore, we will make this single VM can be available for scalability purposes. This article will discuss how to prepare scalability environment for VM with 'least effort'
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Solution
After reading Make all things redundant - Azure Application Architecture Guide | Microsoft Docs, we strongly believe that we need load balancer on our VM and create a snapshot of our VM. On our case, we are very unlucky since the database and the web application is on one VM. Therefore, we need to do some extra steps as follows
Separating between database server and application server. If you are insisting to still make one VM, you will have a risk to lose your data. Snapshot a VM anytime when your database changes is not a good idea. The options are
VM + VM SQL Azure – this is the cheapest one, but you should manage the security and patching by yourself
VM + SQL Azure – if your application cannot be moved to App Service, this is win-win solution
App Service + SQL Azure – this is the most preferred way. Just Be aware of the cost
Replicate the database in multi-region you can do by visiting here
Creating multiple VM with scalability set. On this step, you should create snapshot of your VM and put the VM behind the load balancer. You can do that by reading this tutorial. You can create with snapshot and ARM template to do that.
If you need more than one region. For example, your customer is Europe while your base is in Asia. You can create multi-region VM. You need put the VM behind the Traffic manager. You can read the architecture recommendation here . You should deploy the VM on multiple regions plus you need to maintain the VM by creating regularly snapshot.
Multi-Region in regional pairing. I recommend this one, if your customer still on the same geographical area. Doing regional pair, will make sure that the recovery will be prioritized.
Multi-Region. I recommend this approach if your customer is separated geographically.
Do you have a problem in manage your scalable solution in VM, let's talk!
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";