You might have seen the announcement that Microsoft released Azure Stack integrated systems version 1803 and Azure Stack Dev Kit Build 20180329.1.
Apart from providing an Infrastructure as a Service (IaaS) platform, Microsoft Azure Stack also offers several Platform as a Service (PaaS) features similar to Microsoft Azure. Microsoft originally designed Azure for PaaS-based application development and added IaaS-based services. With the current release of Azure Stack, Microsoft offers four PaaS-based services:
- Microsoft SQL Server and MySQL databases
- App Service for websites
- Key Vault for securely storing secrets such as passwords and certificates
- Azure Functions for serverless compute
Check here if you want to know more about installing and configuring Azure Stack SQL Resource Provider.
Each new build of Azure Stack Dev Kit requires a fresh redeployment, since it’s a single node and there is no way to failover to another node for seamless upgrade. While I am evaluating Azure Stack Dev Kit build 20180329.1, I came across a strange issue when adding a SQL hosting server. In this blog post, I will share with you my experience on how to avoid the same.
Table of Contents
Before adding or introducing any new service to Azure Stack, it’s important to check the health state of the environment. The following high-level steps show you how to check the Health Status in Azure Stack:
- Sign-in to the Azure Stack Administration portal as an Azure Stack Cloud Operator at https://adminportal.local.azurestack.external.
- Navigate to Region management.
- Select the Region you are installing the resource provider into. In this example, since we are using Azure Stack Development Kit environment, it will be the “local” Region.
- In the Settings blade, review the System Health Tests results.
Everything seems healthy and no issue to be noticed. After deploying SQL resource provider in Azure Stack, we can start adding SQL hosting server(s). But before doing so, there are some general requirements which you can read all about them here.
In short, the SKU name should reflect the properties so that users can place their databases appropriately. All hosting servers in a SKU should have the same capabilities. For example, as you add servers, you must assign them to a new or existing SKU to differentiate service offerings. For example, you can have a SQL Enterprise instance providing: database capacity, automatic backup, reserve high-performance servers for individual departments, and so on and so forth.
So while I am adding a SQL hosting server, I received an error message that state Failed to create SKU.
However, as you can see in the screenshot below, the SKU name was populated correctly. I was able to continue and click Create.
But the deployment fails with the following error: Could not find Sku StandardSKU (Core: SkuNotFound)
The error message is clear, the SKU name is not found. However, when I created the SKU, I used the following format and everything seems to be ok.
Fixing the issue
I noticed that when typing the name in the Name text field, it’s required that you type the name without any spaces, otherwise it will throw an error. As for the remaining fields, this is not required.
I checked with the Azure Stack team and they confirmed not to use spaces in any of the four SKU text fields below, so I changed the SKU name to the following format without any spaces.
The SKU was created successfully.
And SQL Hosting Server was added successfully as well.
Last but not least, I was able to create a new database as a tenant and everything works as expected.
Some additional notes
While adding SQL hosting server(s), I also came across important points worth noting here:
- Make sure you have forwarding and reverse lookup zones defined in Azure Stack.
- Make sure to configure SQL hosting VM for SQL Authentication and SQL connectivity as Public. If not, then you can go to the SQL VM and check SQL Settings, and change them there if necessary. Why Public and not Private or Local, because there is no way for the RP to connect to VNETs. And besides, the SQL VM needs to be accessible to all tenants.
- Make sure you use Public IP address and not Private IP when adding SQL hosting server(s), because Private IPs are not reachable from any other VNET.
This issue has been spotted by the Azure Stack team and it will be fixed in the next release. I want to thanks Azure Stack team for their support in this issue.
Hope this helps someone out there.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.