Azure VMs continue to be billed if they're shutdown from within the virtual machine. In Azure management portal, if the VM status is "Stopped", you are still being billed. Only status "Stopped (Deallocated)" means that VM is no longer incurring charges. This is also indicated in http://www.windowsazure.com/en-us/pricing/details/virtual-machines/ .
Also, it's good to keep at least one VM of each cloud service that's not in "Stopped (Deallocated)" state. This is to prevent changes to the IP which require manual and additional steps for reconfiguration. This is because the Cloud Service Virtual IP (VIP) stays with the cloud service it is assigned to, until all the virtual machines in that cloud service are all Stop (Deallocated) or deleted. At that point, it is released. This is indicated in http://msdn.microsoft.com/en-us/library/windowsazure/dn133803.aspx .
This blog post is an attempt to demo such a shutdown so as to reduce billing while also trying to avoid the VIP from getting de-allocated, so as minimize downtime and minimize manual intervention during VM startup.
So let's start and save $$!!
Assume my setup has a domain controller and cluster nodes. All are in the same cloud service (same DNS Name).
DC (Domain Controller) - ContosoDC
Cluster nodes - ContosoSQL1 (primary replica for Availability Group with listener), ContosoSQL2, ContosoWSFCNode.
We'll shutdown all the servers from portal, except the domain controller. The order of shutdown does not matter though typically the primary is shutdown last, so as to prevent an unrequired Availability Group failover. In Azure portal, the status for the VMs should say Stopped Deallocated. An equivalent command in Powershell is Stop-AzureVM (without -StayProvisioned).
To minimize resource/billing further, can remote desktop to the remaining node (Domain Controller) and Shutdown from within VM. It's important not to shut down this last VM from Azure portal, since otherwise the VIP will be deallocated as indicated earlier. This is an optional step, considering the DC may anyways consume minimal resources since there are no VMs connected to it (because they've been shut down through earlier steps). In Azure portal, the status should say Stopped. An equivalent command in Powershell is Stop-AzureVM -StayProvisioned .
Assume off hours have ended and it's time to start the VMs. All VMs can be started from Azure portal.
For each machine that was shut down from portal (three VMs in this case), connect to each of these VMs using a local administrator account. It's important not to use a domain user account, since the shutdown process from Azure portal has changed the DNS mapping for each of these servers, so the VM may not be able to authenticate domain credentials. In my case, "vijayrod" is my local administrator account.
For each of these VMs, go to Network Connections. Change properties of Internet Protocol Version 4 from "Obtain DNS server address automatically" to "Use the following DNS server addresses" and specify the IP of the DNS server (in my case DC and DNS are same server). Click OK to apply changes. This had got changed earlier during VM shutdown from portal.
On primary replica, open Failover Cluster Manager with "Run as different user" and enter domain credentials. Then start Availability Group resources from Failover Cluster Manager. Alternatively reboot primary replica and remote desktop to VM with domain user account.
Verify connectivity to listener from on premise SSMS.
The below should be avoided where possible since it requires manual steps that can increase downtime. The benefits may also be marginal since the last VM (domain controller in this example) is already shut down through a remote desktop connection. If a business requirement requires all VMs to be shut down from Azure portal (Stopped Deallocated), then the same steps like above can be followed. In addition,
SME - SQL AlwaysOn Availability Groups.
There has to be better way of doing this - having to log into each server and reassign the DNS settings is very painful - we're aiming to have a test SharePoint farm with 10+ servers. But we certainly don't want to be billed for having it up and running 24x7, given it will only be used a few hours each week to run some tests.