Managing Your Azure AS Environment with PowerShell – Building Blocks
One of the major value propositions of Azure AS (and this is true for many cloud technologies) is flexibility – spinning up more resources when demand spikes and turn things off when they aren’t – so that you’re only paying for what you need. In order to take advantage of this flexibility, we need to be able to accomplish the following tasks… programmatically…
- Pause/Resume an Azure AS instance
- Add/Remove an Azure AS instance (scale-out)
- Resize an existing Azure AS instance (scale-up)
Note: this post is the second in a series of posts focused on leveraging the flexibility of Azure Analysis Services to maximize performance while minimizing costs. If you’re new to managing azure resources using powershell, I suggest you to start here.
Pause/Resume an Azure AS instance
The quickest win – from an ROI perspective – for Azure AS is the ability to pause the instance during extended periods of inactivity – for example, at night, when there aren’t any users running reports.
This can be achieved via the Suspend-AzureRmAnalysisServicesServer cmdlet we saw in the previous post.
To demonstrate this, I’ve gone ahead and created (through the Azure portal) the following Azure AS:
As you can see, the instance is currently running. To “Pause” the instance, I can run the command below:
# Suspend Suspend-AzureRmAnalysisServicesServer ` -ResourceGroupName "ssas_rg_2" ` -Name "ssasd1"
…and voila, the instance is now paused:
And once I’m ready to start using this instance again, all I have to do is run the following (very similar) cmdlet:
# Resume Resume-AzureRmAnalysisServicesServer ` -ResourceGroupName "ssas_rg_2" ` -Name "ssasd1"
…and voila, the instance is now running again:
And just to be sure there’s no smoke and mirrors happening here, we can confirm the Pause/Resume in the activity log:
Add/Remove an Azure AS instance
The ability to quickly/programmatically add/remove an Azure AS instance is a huge win for folks dealing with a high concurrency environment.
See, when it comes to concurrency – how many simultaneous users can be handled by a single SSAS server – there’s a limit which varies a lot depending many factors. And the approach, in most cases, to overcoming this limit is to implement a query scale-out architecture. The upside with this architecture is that it scales linearly. The downside is that it can be VERY expensive when you start looking at hardware and licensing costs.
Fortunately, with Azure AS, we can programmatically add additional instances when concurrency spikes or delete them when they are no longer needed – though if this is a regular concurrency spike you’ll probably be better off “pausing” the instance rather than “deleting” it.
As you can see below, we have a single Azure AS instance:
To create a second Azure AS instance, we can run the following command:
# Create New Azure AS instance New-AzureRmAnalysisServicesServer ` -ResourceGroupName "ssas_rg_2" ` -Name "ssasd2" ` -Sku "D1" ` -Location "South Central US" ` -Administrator "email@example.com"
We now have 2 Azure AS instances:
Note: the newly created instance will be in a “started” state… so don’t forget to issue a subsequent pause command if you’re just fooling around and want to avoid blowing through your Azure credits… (I don’t want to talk about it!)
At this point, the next logical step for a scale-out query server architecture is to copy the database(s) from one of the existing instance to the newly provisioned one. This is typically done via backup/restore or synchronize… however that functionality has not yet made it into the product.
For example, if you try to synchronize a database across Azure AS instances you get the following error:
Note: If you check the Azure AS feedback page, you’ll see that this is a key scenario they are targeting and plan to address at some point in the future… your vote could speed that up! Backup/Restore, Scale-Out (more generic request)
In the meantime, you’ll have to settle for a more basic deploy+processing to get the database(s) over to the newly provisioned server. Once the data is out there you’ll want to take whatever action is necessary to update the load-balancing mechanism so that it knows about the newly provisioned server.
Deleting is pretty straight forward, we simply run the following command:
# Delete Existing Azure AS instance Remove-AzureRmAnalysisServicesServer ` -ResourceGroupName "ssas_rg_2" ` -Name "ssasd2"
and now we’re back down to a single Azure AS instance:
Resize an existing Azure AS instance
The last section focused on scale-out… but what about scale-up? Well, we can do that too!
Maybe your data is growing and you need more memory for your Azure AS instance… or maybe your user base has grown and you need a bit more CPU (but not quite enough to warrant the complexities that come along w/ a scale-out architecture) to handle end of period reporting… or maybe you just need a bit more processing power to speed up model processing… in each of these cases (and they’re certainly not the only ones) you’re going to want to consider scaling up the server.
With Azure AS this can be accomplished via the GUI:
Note: In the near-future, my guess is that the Set-AzureRMAnalysisServicesServer PowerShell cmdlet will be updated to include the ability to change the SKU. As of now, it only allows you to change the administrators and tags properties (based on a quick scan through the github test code for the Azure AS cmdlets).
Keep in mind…
- only works for S1-S4 (not D1)
- check your memory requirement before scaling down
Clearly there’s still some work to be done on the PowerShell side before we’re at a place where we can fully automate all of the use cases covered in this post – and I’ll be sure to update this post as progress is made. However, what we do have (create/delete/pause/resume) for a “preview” product is outstanding and gives me confidence that we will see a very compelling prime-time-ready offering in short time… especially for folks using Power BI Embedded and not getting the performance they need.