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.
Related
We have an oracle 12 database installed on an Centos VM which works fine for Dev environment with few users. But when we added few more users we start having memory space and performance issue. So we decided to change the VM type to a high performance one.
Is this possible by simply choosing new VM Type in size tab for example from D2S_V3 Standard to D4S_V3 Standard ? or if it is not possible with a live oracle machine.
If you need to change to a size which requires different hardware then you can resize VMs by first stopping your VM, selecting a new VM size and then restarting the VM. If your VM(s) are deployed using the Resource Manager (ARM) deployment model and you need to change to a size which requires different hardware then you can resize VMs by first stopping your VM, selecting a new VM size and then restarting the VM.
Note: Deallocating/Stopping the VM releases any dynamic IP addresses assigned to the VM. The OS and data disks are not affected.
I could change the VM size from standard A1 to B-series in my test lab.
See the screenshot:
Refer the below article to change the VM size by using PowerShell
Resize a Windows VM
It is possible. You could resize D2S_V3 Standard to D4S_V3 Standard.
But it is need restart your VM, if you don't use static VM, the public IP maybe change.
You could resize the VM on Azure Portal.
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.
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.
This is scenario than a specific technical question.
I have two azure vm's who run a web application in load balanced mode.
as per this article http://asheej.blogspot.in/2014/03/load-balancing-using-windows-azure.html
both virtual machines are attached an additional disk which stores images which are referred from web application hosted in vm's IIS.
Now What would be the best way to keep contents on two vm hard drives in sync.
For example, If i delete, add a data from vhd of first vm then that should also be affected on second vm.
Is there anything possible, probably using a common vhd for both machines which will take sync out of question.
Before going into solution , let me briefly touch base on the VM and disk relationship.
Typically a VM contains 3 Disks attached to them 1. OS Disk 2. Temporary Disk and 3.Data Disks. The VM will have lease on all these disks ,the only way to write into data disks is via the VM.
The C: Disk is persistent, meaning when the VM get rebooted the data in the disk is retained. But the D:\ is non persistent , when you reboot the disk will be fully wiped clean. So at any point in time the D:\ shouldn't be used to store any user data.
So writing a process to sync between two VM's just to keep pictures in sync is not very ideal. You might know this already , but wanted to set context for the choice of options provided below.
Your potential options are as follows
You can setup File Share using the new Azure File Service (In Preview) http://blogs.technet.com/b/uspartner_ts2team/archive/2014/06/09/setting-up-a-file-share-for-the-new-azure-file-service.aspx. This will be single source for all your images and you don't need to worry about syncing of files.
2.Store the images in the Azure Blob and access them from the application that's running in the VM http://blogs.msdn.com/b/yaohuang1/archive/2012/07/02/asp-net-web-api-and-azure-blob-storage.aspx and http://www.nickharris.net/2012/11/how-to-upload-an-image-to-windows-azure-storage-using-mobile-services/
3.Host another VM as a Webserver and host your images from there. Then the two VM's can refer the image. The cost here will be to hosting the VM.
The key point with all the 3 potential options there is no need sync the files in two different places , everything is in single place.
Edited based on new information:-
In your scenario hosting your files into VM is not the right approach. You should take the following into consideration even for the short term solution , if you are using Azure LB.
Azure Load Balancer uses a 5 tuple (source IP, source port, destination IP, destination port, protocol type) to calculate the hash that and map traffic to available servers and also the distribution is fairly random. So if you load balance the VM, you cannot control which VM the images are accessed.
Manual updates is not possible in this scenario.
You either need to setup an virtual network to allow you to create and share a windows file share OR you should investigate the use of Azure File Service for creating a share that both VMs connect to (see: http://blogs.technet.com/b/uspartner_ts2team/archive/2014/06/09/setting-up-a-file-share-for-the-new-azure-file-service.aspx).
I would like to achieve a high-availability scenario on two VMs in Azure.
I understand and can follow the directions here:
https://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/
However, my question is this: are the two VMs supposed to be exact replicas of each other, so that when one goes down, the other takes over? Or does the Availability Set look after this, so that the two VMs can have totally different content and still utilise each others' free resources?
If you're working with Virtual Machines (currently in Preview), then each VM lives in its own VHD. You can make additional instances by creating a VM from an image you build, but at that point, the new VM lives in its own VHD and the actual disk image will then deviate from any other instance as time goes forward. Of course, if each VM is created from the same image, with the same initialization tasks, etc., then they'd have the same software as well. You'd be responsible for upgrading software versions on all the VMs. If you then put these multiple Virtual Machines in an Availability Set, you'd be assured that the Host OS (underlying OS at machine-level) for the VMs you have would not be updated at the same time. You'd also know that different VMs in the Availability Set would be situated in different racks, network segments, etc.
More on Availability Sets: Within an Availability Set, you may have any variety of Virtual Machines - Linux, Windows, different functionality. And... you may define more than one Availability Set.
In the PaaS world, where you set up a Cloud Service with Web and/or Worker roles, those VMs are spawned the exact same way. So adding instances means adding more of the equivalent VMs. If the disk crashed, a new VM would be created just like the others. There are no persistent changes to those OS disks. In the case of Cloud Services, there's fault domains and upgrade domains, which are very similar to availability sets.