When a Sql Server VM (IaaS VM) is recycled (for whatever reason, hardware failure, etc) and comes up on a different VM) can my app continue using the database (once the new VM comes up) automatically or do I manually have to restore the database? Do I manually have to attach the disks again? Even if the disks are attached automatically, will the database restore also happen automatically? If the disks are available automatically, will my data files also be present on the new VM?
In case of a hardware failure, the experience to the guest O/S - your SQL Server VM - would be as if someone had pulled the power cord and restarted the server. configuration of the VM will remain the same, including all attached disks etc. but operations that were not yet persisted to disk may have been lost. the impact depends on how you use the server in terms of transactions etc.
I believe that scheduled maintenance is a bit more organised and the VM will be shut down in an orderly fashion increasing the consistency for your application.
Related
I have a VM with SQL Server and an application that uses no more than 50 users. I don't require to have a zero downtime application in case my VM or datacenter had an issue, but what I need at least to assure is that I can make the app available again in less than 30 minutes.
First approach: using an Availability Set with 2 VM's won't work actually because my SQL Server lives in the same VM and I don't think Availability Set will take care of the real time replication of my SQL Server data, it will care only about the web application itself and not the persistent data (if I'm wrong please let me know), so having the above statement AV Set is not for me. Also It will be twice expensive because of the 2 VMs.
Second approach: using Recovery Site with disaster recovery I was reading that wont warranty to have a zero data loss, because there is a minimum frequency of replication and I think is 1 hour, so you have to be prepared to deal with 1 hour of data loss and I don't like this.
Third option: Azure Backup for SQL Server VM, this option could work the only downside is that has a RPO of 15 minutes that is not that much, but the problem is that if by some reason the user generates in the app some critical records we wont be able to get them again into the app because the user always destroy everything right away when they register into the app.
Fourth approach: Because I don't really require a zero downtime app, I was thinking on just having the actual VM using 2 premium disks one for SQL Server data files and other for SQL Server logs. In case of a VM failure I will get notified by users inmediately and what I can do is to create a snapshot of OS disk, and SQL premium disks (total of 3) and then create a new VM using these snapshots, so I will get a new working VM maybe in a different region having the exact very last data inserted into SQL before the failure happened.
Of course I guess I will need on top the VM a load balancer so I can just reroute traffic to the new VM. The failed VM i will just kill it and use the new VM as my new system. If fail happens again I just follow same process so this way I just only pay for one VM and not two.
Is this someone has already tried, does this sound reasonable and doable or Im missing a big thing or maybe I wont get what I expect to get?
You better use Azure SQL (PaaS) instead of VM, there are many different options that you can do for your needs. Running SO + SQL in the same VM is not recommended, changing to a Azure SQL (PaaS) you can decrease your hardware for SO VM and configure your SQL for supporting 50 users. Also you can use Load Balancer as you said, either Traffic Manager (https://learn.microsoft.com/pt-br/azure/traffic-manager/traffic-manager-overview) or Application Gateway (https://learn.microsoft.com/pt-br/azure/application-gateway/overview) to route traffic to your SO VM's where the application is running. Depends on your application you can migrate to Azure Web App (https://learn.microsoft.com/en-us/azure/app-service/).
Azure SQL (Paas) you can have less than 30 minutes for sure, I would say almost zero down time although you don't required it.
Automatic backups and Point-in-time restores
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-automated-backups
Active geo-replication
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-active-geo-replication
Zone-redundant databases
https://learn.microsoft.com/pt-br/azure/sql-database/sql-database-high-availability
Finally I don't think having Always-on (https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15) solution is good, once it is expensive and there are only 50 users. That's why I believe you better thinking of a Saas + PaaS solution for your application and database. Your 4th option sounds fine, but you need to create a new VM, configure IP, install SQL, configure SQL and so on to bring up your SQL.
What users is going to do if it happens when you are not available to fix it immediately? Your 30 minutes won't be accomplished :)
Currently I am working on test automation, I am considering two options now in term of saving cost for Azure VM. The test automation runs daily.
Host the virtual machine and shut it down when the automation process completed
Destroy the virtual machine when automation process completed and create the virtual machine again the next day.
I need some expert view on this, which option will save the cost more?
option 2 will save more money if you will delete the virtual disk as well. if you are not going to delete the virtual disk (so your vm creation process is not 100% automated) its easier to deallocate it (it will still cost you money if its just stopped, not deallocated). And strictly from the perspective of billing deallocated or deleted VM both cost nothing.
But you cannot stop a virtual disk, only delete it.
If I setup a server running my application on an azure instance, for example A1 can I later change the instance to D2?
I might want to experiment with a VM at a lower cost but then move to a higher performing machine at a later date without having to rebuild everything.
Yes, you can change the size of Azure VM on demand. Changing the size will trigger a machine reboot and if you're using a configuration with SSD temporary drive, the content of the SSD will get erased. Other than that, everything else will be left untouched.
Drew, the Principal PM in this area has a great blog here about this.
You can only resize a VM to another offering that does not have fundamentally different hardware. Since A-Series and D-Series VMs have similar hardware, you would be able to swap those two around. You would not be able to go from A-Series to G-Series though. In addition you need to look at VM availability per region if you want to swap to something only in certain areas, as well as look at if you are using an ASM or ARM VM.
If you have an existing VM, you can check what it can swap out with in the new portal under "Size" in the VM Settings.
This will allow you to reboot into a different machine type, however any temp storage will be erased as with any VM reboot. You just need to ensure you are storing your persistent data in external storage.
You can learn more about the VM size offerings here.
I am currently working on achieving 99.95 % Availability of my application residing on Azure Virtual Machine.
What I want to achieve is that whenever the machine is restarted due to windows update or fault restart, another machine in a different "update domain"/ "fault domain" should take over. I ran across the following issues:
Storage High Availability: My application resides on wwwroot folder and has dynamic folders that contain Document database (CSVs, PDFs, Txt ...) Created by the application users. I cannot move to "Azure Web Application" because the files are accessed via virtual path: "~/Users/CSVs/4.csv". Moving to BLOB storage is a solution that requires a lot of changes on my infrastructure and web application code as multiple other components are involved (Windows Services & Scheduled Tasks Executables are also accessing the same files via absolute path: "C:/inetput/wwwroot/ApplicationFolder/Users/CSVs/4.csv"). I moved the whole application to Data Disk (VHD) different than the OS Disk and attached it as a new simple volume hoping to re-attach the same VHD to another instance. This is not allowed in MS Azure. Any recommendations away from using BLOB and away from SMB Protocol?? :)
SQL High Availability: I use SQL Dependency to query notifications from SQL Server to the application level and auto-update the UI using SignalR. This requires Service Broker to be enabled on the database. Service broker is not accessible in SQL Azure. Any other recommended way to query changes on a specific query without using SQL Service Broker and without overburdening the server by querying new notifications via Ajax timeout?
I am open to any hybrid high availability architecture suggestion for my IaaS solution rather than going full PaaS.
Any Suggestions Architects?
Thanks
I just tried it myself and it worked; specifically, I:
Spun up two Ubuntu VMs
Used the XPlat CLI to attach an empty disk to VM1 ('azure vm disk attach ...')
Mounted the disk and put a file on it called 'hi.txt'
detached the disk ('azure vm disk detach ...')
attached the same disk to VM2 ('azure vm disk attach ...')
Mounted the disk on VM2 and found the file 'hi.txt'
This was all in Linux, following this blog post for linux-specific commands: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-how-to-attach-disk/
Here is a link that will hopefully help for Windows: https://azure.microsoft.com/en-us/documentation/articles/storage-windows-attach-disk/
One thing to note is that I did everything in ARM mode; the tutorials above assume Classic/ASM mode, but this is not necessary.
Hope this helps! :)
I have deployed a Worker Role to an Azure instance with remote access enabled.
When I remote to the server, I see disks C: and D: on the server.
I was told that Azure doesn't guarantee the durability of data stored in compute instance. However when I reboot/upgrade the service, I still see the previous data on disks C: and D:.
When will the data on disks C: and D: be lost?
Local disks are non-durable disks. In other words, not replicated. They may fail at any time and offer you no way to recover this data.
During role recycles (reboots), data typically will survive, but you cannot count on it surviving.
If your software must use a drive letter because you can't alter the code base, you can mount an NTFS volume inside a Page Blob (basically a Cloud Drive). You can do this from your OnStart(), then pass the drive letter to your app. Note: a cloud drive may only have one writer. So... if you have multiple instances, each instance would need to create its own cloud drive.
Because Azure is a cloud service, the hardware that your instance is running on is not guaranteed to be the same at any given point in time. As a result, you shouldn't rely on the data being present. Even though it may persist across reboots/upgrades, it isn't guaranteed.
See the second paragraph on Local Storage from this article. It makes the following recommendation:
If you require reliable durability of your data, want to share data between instances, or access your data outside of Windows Azure, consider using a Windows Azure Storage account or SQL Azure Database instead
It will usually be there after a reboot, but I have seen one case where I rebooted and something went wrong, so the instance was reset to a clean state. You cannot rely on the data surviving. I would imagine the same thing could happen with an upgrade.
Stopping and starting the instances will also probably lose the data, but I haven't checked.
Here's a quote from an MVP on the MSDN forums:
The local disk storage of Compute VMs (whether Web Role, Worker Role, or VM Role) is not persistent. It can go away at any time. The data center has the right to move and re-create your VMs whenever it deems it necessary. This could happen in response to a hardware failure, or simply because the data center needs to be reorganized. When this happens, you lose your VM disk files and go back to your deployment image. It is only a matter of time before this happens. This is normal behavior for cloud computing compute instances.