How to shutdown and start an Azure Stack system.

28 Jan

I’ve been intending for a couple of months on how to shut down an Azure Stack integrated system ‘the right way’.  Why?  Because I had to turn off an instance a couple of months ago due to the location hosting the appliance having planned utility maintenance (it hosts pilot/demo kit only so no need for generators), and didn’t want any issues with tenant workloads or S2D.

Anyway, I don’t particularly need to detail the process now as Microsoft have recently updated their documentation detailing the process (get it here).

So, why did I feel the need to make this post?

Primarily, it’s to highlight the importance of regularly checking back on the Azure Stack doc pages; they are constantly adding and updating the guidance, especially when new code updates are released.  The link provided pertains to version 1712 and above.  The  Test-AzureStack PowerShell CmdLet has been added to this version, allowing the operator to confirm that all required Azure Stack roles and services are functioning.

Secondly, I wanted to show give some more detail on the steps, output you will see and time it can take for each stage.

Stop-AzureStack

Here’s the high level steps of what happens when you stop Azure Stack:

Connect to the Privileged Endpoint via PowerShell Remoting

$Pep = 'azs-ercs01'
$cred = Get-Credential -UserName 'azurestack\cloudadmin' -Message 'Enter CloudAdmin Password'
enter-pssession -computer $Pep -ConfigurationName PrivilegedEndpoint -Credential $cred

Change the $Pep variable to match the name or IP address of one of the ERCS VMs.
Change the domain name to match that defined when the integrated system was deployed or leave as-is for ASDK deployments.

Start the shutdown procedure

 
Stop-AzureStack
 

You’ll see some verbose output on the progress:

 

As you can see from the image above, the following tasks are carried out when you run the command:

  1. The tenant VM’s are shutdown (actually saved if you were to check Hyper-V Manager)
    • This includes servers required for PaaS
  2. ADFS and WAS (portals) are shutdown
  3. Fabric Ring services are shutdown (Resource Providers)
  4. Azure Consistent Storage VMs are shutdown
  5. Azure core infra SQL servers are shutdown
  6. Gateway VMs are shutdown
  7. Software Load Balancer VM’s are shutdown
  8. Border Gateway Protocol VM is shutdown
  9. Certificate authority VMs are shutdown
  10. Network Controller VMs are shutdown
  11. Finally, the physical nodes are shutdown

The time it takes to complete is dependent on the number of tenant workloads and PaaS servers you have running

If you close down the session that you ran the command from, you can still check on the progress by connecting to the PEP again and running the following command:


Get-ActionStatus Stop-AzureStack

Start-AzureStack

When you’re ready to power the appliance back on, here’s what you need to do:

  • Power on the physical nodes.
    • If you have an integrated system, ensure that you power on all nodes at the same time, otherwise you may find yourself having issues due to S2D re-balancing
  • After a period of time (around 10-15 minutes), connect to the HLH and connect to the PEP via PowerShell Remoting (use procedure detailed earlier)
    • The only VMs that will be running on the nodes will be the DCs and Emergency Recovery Service computers
  • Run the following command:
start-AzureStack

 

You’ll get to see something that looks similar to this:

For some reason, the logging is not as ‘verbose’ as I would like.  You’ll see lots of this:

Rest assured, things are happening, although it’s not clear! I did try running the command again once it had completed and I did see the correct verbose messages.  Not sure what happened first time round:

Here’s the process

  1. Wait for DCs to start
  2. Wait for storage to be ready (S2D cluster)
  3. Start Network Contoller VMs
  4. Start Certificate Authority VMs
  5. Wait for Certificate Authority Service
  6. Validate Certificate Authority.
  7. Start BGP VMs
  8. Start SLB VMs
  9. Start Gateway VMs
  10. Start GW service
  11. Start SQL VMs
  12. Start SQL Cluster
  13. Azure Consistent Storage VMs are started
  14. Fabric Ring services are started (Resource Providers)
  15. ADFS and WAS (portals) are started
  16. Wait for WAS (admin) portal start-up
  17. Wait for WAS (Public) portal start-up
  18. Finally, the tenant VM’s are resumed

If you want to see what the progress is, use the Get-ActionStatus Cmdlet:


Get-ActionStatus Start-AzureStack

You’ll need to decipher the output, but it’s not entirely unreadable:

As with stopping the instance, times will vary.  Expect it to take from between 1 – 2 hours, dependent on Tenant workloads and if you have any PaaS services installed.

Here’s what I saw when I first ran the command:

The output above indicates it’s still in progress, so at this point i ran the Start-AzureStack command again.  This time I got the verbose output I would expect to see:

After another hour, eventually I got the following output:

Status: Completed

Just a note on this: Although I ran the Start-AzureStack command again, I also ran the Test-AzureStack command in parallel.  It reported that all tests passed, so go figure what was actually happening.  I trust the tests, so use those as the gate to release the instance back into production.

Test-AzureStack

All being well, once the Start-AzureStack command has completed, you’ll have a fully operational system.  You *could* resume normal operations and trust it’s working.  for peace of mind, I prefer to know that everything is working before letting it back into the wild.

The Test-AzureStack Cmdlet runs a number of tests that will give you the reassurance.

Test-AzureStack

 

Run the command from the PEP and after  a few minutes you should see output like this:

Anything that doesn’t pass, you’re going to need to speak to Microsoft support 🙁

Remember to close the PEP session. Either:


Close-PrivilegedEndpoint -TranscriptsPathDestination '\\yourserver\share' -Credential (get-credential)

Or:


exit-pssession

 

Danny McDermott

Danny is a Cloud Architect within the Azure Cloud Enablement Team, based in the UK.

Twitter LinkedIn