I explicitly created an Availability Set via the Azure console. I can launch VM's in successfully by selecting the Availability Set.
When I review the Availability Set in the console, I do not have an option to edit the Fault Domain or Update Domains values.
Are there options to perform this Action?
Yes, you can use REST api, or resources.azure.com to edit those values. Powershell\Cli have commands to edit those (Update-AzAvailabilitySet).
It appears these values are read only after creating the resource
Related
I have a AvailabilityZone set to my deployed VMSS, i would like to know how can i add and change AvailabilityZone to my current vmss but i cant find any option to do so.
I would really appreciate any inputs
Change the Availability Zone Sets
You can't add an existing VM to an availability set after it's created. VMs must be created within the availability set to make sure they're correctly distributed across the hardware. A VM can only be added to an availability set when it is created. To change the availability set, you need to delete and then recreate the virtual machine.
Please refer to the below documents for more information :- https://learn.microsoft.com/en-us/azure/virtual-machines/windows/tutorial-availability-sets
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/change-availability-set
When I try to create a backend pool in the azure portal, I don't get prompted for an availability set; I just see a drop-down list of virtual networks but the list is empty.
When I first tried this I didn't know about availability sets. I have now created an availability set but I still don't get any option to select an availability set either when creating a backend pool or when creating a new VM.
I have seen tutorials and videos on setting up load balancing on azure, but on my azure portal I just don't see the same options they have in the screenshots.
Are availability sets still relevant or are they now deprecated? if they are still in use, is there anything I need to do to enable them?
Availability Sets are not deprecated.
If you create an Availability Set in the same Resource Group with the Load Balancer you must be able to see it.
And one more thing, when you must select the Availability Set while you create a Virtual Machine you cannot add it if the virtual machine already exists.
Hmm, after looking more closely I realized that in the 3rd step for creating the VM, the screen wasn't loading completely. As well as the Availability Set selection being completely blank, a couple of the other drop-down boxes just said "loading..." next to them so basically I couldn't create a VM at all.
I tried waiting for a while, logging out and back in etc but it made no difference. I tried on a different Azure subscription and everything worked as expected. The original subscription used to work, so I suspect my Availability set had somehow not been created properly and this was causing the screen to bork.
I deleted the Availability set and created another one with all the same parameters, and now it seems to be working properly.
What is the difference between updating an deployment and deleting and then creating a new deployment for a cloud service ?
We have a cloud service set up which during deployment, first deletes the existing deployment in staging and then creates a new deployment. Due to this the VIP for staging is always changing. We have a requirement where we want to make sure that both the PROD and Staging VIP always remains same.
Before changing the deployment option i would like to know what is the real difference and the need to have these two options.
I tried to search but found nothing on this.
EDIT: In the Azure Pub XML, we have a node named 'AzureDeploymentReplacementMethod' and the different options for this field are 'createanddelete', 'automaticupgrade' and 'blastupgrade'
Right now we are using 'createanddelete' and we are interested to use blastupgrade.
Any help would be much appreciated.
THanks,
Javed
When you use Create&Delete deployment the process simply deletes an existing deployment, then creates new one.
The other two options do upgrade deployment. The difference between automaticupdate and blastupgrade are in the value of Mode element of the Upgrade Deployment operation. As their name suggests, automaticupdate sends Auto for that element. While blastupdate would send Simultaneous. As per documentation:
Mode Required. Specifies the type of update to initiate. Role instances are allocated to update domains when the service is
deployed. Updates can be initiated manually in each update domain or
initiated automatically in all update domains. Possible values are:
Auto
Manual
Simultaneous
If not specified, the default
value is Auto. If set to Manual, WalkUpgradeDomain must be called to
apply the update. If set to Auto, the update is automatically applied
to each update domain in sequence. The Simultaneous setting is only
available in version 2012-12-01 or higher.
You can read more on Update Cloud Service here.
Although, if you really want to persist VIP in all situations, I would suggest you to:
Do not use staging for cloud services at all - just use two separate cloud services (one for production and one for staging)
use the Reserved IP Address feature of the Azure Platform.
I am not very familiar with this in azure.
I created one centos vm, I created an availability set, in order to enable auto scaling I need to create another VM in the same availability set.
so I will create another vm, with the same image.
So, these 2 vms will replicate each other? if I install something in one VM, will it be replicated automatically to the other vm?, should I use only one of the vms as the starter point to install and configure things?
or should I do everything manually on each VM? Example, if I open port 80 in one I should do it in another?, if I install magento in one, I should install it in the other?
Azure will not replicate your VMs automatically. There are some manual steps involved:
You need to prepare one VM as a starter point.
Then you manually clone VMs up to a maximum number that you will need.
Make sure all they are in the same availability set.
Set up auto scaling
Now Azure will scale automatically by turning some of your VMs on and off. When VM is turned off, you will only incur storage costs for it. And storage in Azure is almost free.
To answer your first question: How to configure availability set
I created a post covering this on How to guard your application from azure outages
Use the quick create to stand up a VM of your choice
Once the instance is running click on the configure tab and create a new availability set
Click save
Saving will force a shut down, reconfigure, startup process
Once the VM comes back online you can create a 2nd VM
Using the create from gallery option, click through all the create screens until you get to the configure virtual machine screen (screen 4 at the moment)
Select the cloud service that was created with your first VM (availability sets require the VM's to run in the same cloud service)
Then select the availability set you created for the first VM
Finish the creation of your second VM
You can now see the linked VM's in the same availability set by clicking on the configure tab for any VM in the availability set you created. It will list all VMs in a given availability set inside the details of the VM
I just created a standard vm inside Azure, and created a new Availability set.
I created another vm, with the same specs, in the same region, but when I go to configurare the availability set I don't see it in the list.
I'm missing something?
Luca
So... just posting this as an answer, to properly close the loop based on the comments under the question:
When setting up a Virtual Machine, you can choose which Cloud Service to place the Virtual Machine in. The Cloud Service is essentially a container which gets assigned a specific IP address, gets a cloudapp.net name (e.g. myservice.cloudapp.net), and gets assigned to a region (or affinity group, which is region-specific).
Availability Sets are specific to a given Cloud Service. You may place any of your Cloud Service's VMs in the same Availability Set (or even have multiple Availability Sets, with groups of VMs assigned to specific Availability Sets). However: An Availability Set does not span across Cloud Services.
So: When you went to set up your second Virtual Machine, and you didn't see your Availability Set, that is because you were attempting to deploy to a different Cloud Service.
Below screenshot shows the wizard page where we can select existing cloud service to which we can associate a new VM