I have three questions that I couldn't get a clear answer for in the documentation I visited.
1- In case I deployed a VM scale-set with auto-scaling and I had a VM that was scaled-in (according to the set policy) then it remained active for a while and after that, it was scaled-out after the utilization got back to normal. My question here is what happens to the data generated by the VM that was scaled in, then out (ex: logs) in case I was using Managed storage. Noting that the aim here is to persist important data (app logs...)?
2- As per what I understood from the documentation in order to update your app code for example (using SCM ex Git) on all the scale set nodes you will need the help of an automation tool (ex: ansible), or you'll need to update the custom image and redeploy it to the scale set. Is there a more centralized way that I missed?
3- Is there a way to add an existing VM to a new scale set other than converting it to a base image?
thanks in advance.
A1. If you do not set the persistent storage, then the scale in will just delete the instance without persisting the data in the VM.
A2. There is no other way to update your code, the best way is to change your VM image. Or use storage to store your code and then mount the storage to your VMSS. For example, the
Azure file share.
A3. No, you can't add other existing VMs to VMSS. It's impossible.
Related
I have 4 VMs in azure and I am trying to set up a schedule to lower the RAMs and CPU cores for after-hours and revert them back to their original size during business hours.
can someone guide me through the steps or share a how-to resource, please? I can't find any documents and I am sure my search key is not correct.
Thanks
As suggested by #harshavmb, you can make use of VMSS.
In Azure, Auto-Scaling is possible if you make use of Virtual Machine Scale-Sets.
Virtual Machine Scale-Sets allows you to automatically scale as resource demand changes.
Based on schedules, you can create auto scale rules.
These schedule-based rules allow you to automatically scale the number of VM resources at fixed times.
To create the Auto-Scale rule, you can make use of following tools:
Azure PowerShell
Azure CLI
Azure template
Otherwise, you can create an automation account in Azure and execute runbooks as mentioned in below link if helpful:
Automatically Resize an Azure VM - Automation account
I have a azure vm setup that contains custom software, files, folders blah blah. At any point I will need to create multiple identical instances of the existing vm (maybe up to 30). I used the sysprep in the vm, in the azure portal I used the capture image for the vm and tried to create a new VM from the image. The new vm created from the image did not contain any of the files from the previous vm.
What would be the best approach in preserving a complete image of the vm and be able to mass deploy from it at any given time?
I'm not sure what you do makes the file disappear, but on my side, it works well. Sysprep just removes all your personal account and security information and then prepares the machine to be used as an image. You can see the feathers of it from Sysprep overview.
To create a custom VM image, see Create a managed image of a generalized VM in Azure. I suggest that creating an image directly from the VM ensures that the image includes all of the disks associated with the VM, including the OS disk and any data disks.
For the creation of multiple identical instances, you can use the Azure VM Scale Sets. The VMs are identical, load balanced in a group, so if you want to specialize one of them, you need to specialize all of them through a custom image.
Also, you can use the Azure Template to create multiple individual VMs, they are 他the independent VMs, you can specialize any one of them, not all of them, but uniform management is a little difficult.
You can get more details about the difference between them, see Differences between virtual machines and scale sets.
I created a scale set with managed disks and a custom image (something like /subscriptions/<SUB-ID>/resourceGroups/my-rg/providers/Microsoft.Compute/images/my-base-image) and also an ARM template to deploy a new scale set with this custom image.
The template deployment works fine if I deploy to the same subscription where my custom image is located. But it fails when I try to deploy it to another subscription - even if these two subscription are part of the same tenant/directory and the user has access to both subscriptions.
So am I right that it's not possible to use a custom image from a different subscription?
If yes: it would be ok (not best solution, but ok), if I could copy the custom image from subscription A to subscription B - But I can't see a way to copy this ressource. I think the only way is to recreate everything and use unmanged disks, because here I can download and upload the .vhd file from/to the storage account.
Any other ideas?
For now, Azure doesn’t support move a managed Image to anther subscription .But, this function will come soon. Also , I supply a way for this issue.
Create a temporary VM in A subscription using your Image.
Move this temporary VM to B subscription.
Capture a new Image and delete the temporary VM.
Then, you can use this image to do what you want to do.
NOTE: Moving a VM to another subscription is very easy. You just need to click Move button on VM’s overview in portal.
Also, this link supply another solution and it may be helpful to your case.
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.
We have a few servers in Azure that are running the same service. We would like them to be part of the same availability set. How do you add these servers together in the same availability set if they were not created in the same cloud service when they were created?
It looks like I would need to rebuild these VM's? If so that kinda sucks.
Please let me know if anyone knows a better way.
Thanks in advance.
Once a VM is created, it can't join an availability set.
However, the image for the VM is available in storage. So, new VMs can be spun up, using the image, this time adding them to the set. And rebuilding the VM from scratch is not needed.
Edit:
I've used the method above to bring up a VM, but I had forgotten that if your VM is running already, capture is the way to go. I'd suggest these steps:
Capture the image of your current VM. This will run sysprep on it, so you will want to be careful with it. (spin up a test VM and play with the steps until you feel confident to move to a production box)
Then when you create a new VM, specify your captured image and your availability set. Then the machine will come up with all your services running in the new set.