I am trying to deploy a nodejs app on azure vm but I keep reading that the vm machine can crash or restart.
So lets say I opened the vm and installed nodejs and all the required tools I need then I get my code from github and started it, now every thing is running okay.
I am wondering what would happen if the vm restarted/crashed? Will the tools I downloaded and my code be lost? how can I make the vm when it start to redownload the tools, setup the environment, download my code then run it?
Azure Virtual Machines use Azure Blobs to back the OS disk VHD, as well as any attached data disk VHD. So, for those disks, everything is durable, regardless whether the VM is running or not (or crashes).
VMs also provide temporary storage on ephemeral disks. Assume anything placed on these temporary disks can, and will, disappear upon crash/restart.
So if you install any type of code libraries, apps, etc. on OS or attached disks, things remain in place unless you decommission the VM (and related storage), or delete it yourself.
Lots of documentation around Azure Virtual Machines and Storage, which can provide additional details.
Related
We have 2 Ubuntu VMs inside Virtual Machine Flexible Orchestration that are behind Application Gateway and are running Apache Tomcat web servers. When a client connects to one of the VMs and uploads the files that files also need to exist on another Virtual Machine.
I only found 2 options to do that:
Azure File Share - $80/month for 1 TB of Hot SKU, but the speed is only 1 MBs when mounted as SMB share on Ubuntu.
Azure NetApp Files - $600/month for 4 TB minimum.
Both of the options are not good, the first one is to slow and the second one is too expensive. What can we use in the development environment and production environment to achieve file sharing between Highly Available VMs?
1MBs is awfully low, I am not sure where this is coming from. I am fairly sure I get about 30MBs for Standard SSD/HDD deployments when mounting them into Linux docker containers, which should not perform worse.
An alternative to the mounted file shares would be to use shared disks. You can basically attach a disk to multiple VMs at the same time.
There are some limitations, for your case mainly mainly:
Shared disks can be attached to individual VMSS instances but can't be defined in the VMSS models or automatically deployed.
You can still expect to pay 50-200$ for the disk, but you should be able to get much better speeds than what you are currently getting.
Use a Blob and grant access via Managed Identity to your Virtual Machines:
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-vm-windows-access-storage
Blob Pricing and IOPS:
https://azure.microsoft.com/es-es/pricing/details/storage/page-blobs/
Can we use a virtual machine (Machine A) to take the backup of another virtual machines snapshot(Machine B). If we can do it what setup should we make (in machine A). Can you give me a working example with some real virtualization techniques.Assumption is that both the virtual machines are running on some cloud virtual machine management services for example like ovirt
Although it is a general question, I think the feature you are really looking for is snapshots.
I use a lot of cloud based VMs, most cloud provider offer you to snapshot your volumes, this is the preferred way to do backups in the cloud as it doesn't require you to stop or slow down your VM the back up is done at the disk level.
Later on you can restore your backups by creating an image out of your disk snapshots and spinning a new VM with this image.
On the other hand if you really need to backup a running at the filesystem level, you can have a look at rsync on linux/unix hosts. For Windows sorry I don't have a clue...
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! :)
We have SQL Sever setup on A-series virtual machines. We are wanting to upgrade to the D-series virtual machine. Is it as simple as just upgrading the VM in Azure and clicking save or are there any other things I need to watch out for? I have heard of people having issues upgrading due to the level not being available in the cluster that their Virtual Machines sit in.
The hardware infrastructure used for A series VM is not suitable for D series VM. It might be possible that the cluster where the VM is hosted, has the hardware configuration required for creating A series VM alone.
However if you would still want to change from A series to D series VM, you will have to export disks and create a new VM using the previously saved disks.
Going forward as a workaround: when you create your very first VM in your Cloud Service, be sure to specify one of the D-SERIES size even if you do not need it immediately. Doing this, your Cloud Service will be “tied” to a cluster that will support both A-SERIES (except A8/A9) and D-SERIES, then for all the future VMs contained in the same Cloud Service. Now, you can create additional A-SERIES VMs and mix together in the same Cloud Service. If you do not need the first D-SERIES VM, you can now safely delete it.
If the D-series machines are not available due to the cluster, you can always delete the vm (preserve the disks) and create a new VM of the D-series and attach the existing disks to that system.
When you create the new VM, choose the option to 'create from template' and the select your OS disk from the 'My Disks' section. Then attach all the data disks to the VM once it's provisioned.