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.
Related
As I understand, Virtual Machine Scale Sets are a collection of Virtual Machines. Each one can be destroyed and reconstituted at the whim of the configuration. The VM's are recreated from a certain image. Is this understanding is correct ?
If this is correct, how do you patch a scaleset ?
Consider a scaleset created using a Windows 2016. 50 patches are made available via the update service since the base image was created. During a heavy load, 3 new VMs are created by the scaleset. The new VMs should load 50 patches before even going on-line. That could take hours. The patches might not work at all.
What is the best practice to handle this issue ?
I would like to suggest to create the VMSS from a custom image. You could first deploy a windows 2016 and install the 50 patches, then make this as a custom VM image. This custom VM image includes any required application installs or configurations. Any VM instances created in the scale set use the custom VM image and are ready to serve your application traffic. In this tutorial you learn how to:
Create and customize a VM
Deprovision and generalize the VM
Create a custom VM image
Deploy a scale set that uses the custom VM image
You could make it with multiple methods.
Tutorial: Create and use a custom image for virtual machine scale sets with Azure PowerShell
Tutorial: Create and use a custom image for virtual machine scale sets with the Azure CLI
Add a custom image to an Azure scale set template
The Windows Server images in the marketplace are continually updated (at roughly a monthly cadence) with all of the latest patches. Installing the latest version is a good starting point to keep your instances up-to-date.
In order to stay up-to-date on existing instances when new images are released, you can enable automatic OS image upgrades, which will safely update instances in a rolling fashion when a new version of the image is available.
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'm installing OSISoft on a single windows 2008 VM in Azure and part of the instructions recommends having 4 drives for each application. However Azure will only allow 2 disks be attached to a VM. What alternatives do I have?
You need to use data disks and choose the different VM size - the VM size determines the amount of data disks that can be connected.
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/
Tutorial:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-attach-disk/
I see there are some limitations on Azure:
1. On number of disks to be attached to VM;
2. The size of each disk/storage blob is limited by 1TB;
Is there any hack or workaround to attach larger disks/several disks to the same VM without increasing the processing power of VM as my application doesn't need high computing capacities, but needs plenty of space.
May be it's possible by contacting their billing department?
Currently I'm using A1 Standard VM instance with 2 disks (2 TB it total) attached to it already. The goal is to attach 5 TB total disk space to the same VM without upgrading the VM size to a larger instance.
You will need to change your VM size to attach more disks. One option is to look at Basic tier instead of using Standard tier A Series VMs to optimize your cost. Since you do not need a lot of computing power, basic tier VMs may work fine for you. You will want to look at Basic A3 which will allow you to attach 8 maximum data disks of 1 TB each. See more information here (https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs/)
Thanks,
Aung
I found a solution to attach 5TB folders as Azure File Sharing service.
It's possible via creating File Sharing containers through Azure Portal, then mounting the folder under Linux via CIFS (SMB3.0).
For those who are interested, there is an issue with mounting Windows File Sharing folders within CentOS 6.X under Azure. It works only with CentOS 7.X (keep it in mind).
You can use Storage Spaces in Azure to increment capacity and performance. The limit of the VHD is 1 TB per disk, using Storage Spaces you can pass this limitation. You need to have in mind that there is a limitation of disk to attach to the VM based on type you choose.
Sample explanation on:
https://blogs.msdn.microsoft.com/dfurman/2014/04/27/using-storage-spaces-on-an-azure-vm-cluster-for-sql-server-storage/
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.