5 min. Read
Azure Stack’s App Service Resource Provider is a PaaS-based service deployed and maintained by Azure Stack Cloud Operator.
Users and tenants can use the App Service Resource Provider to create web apps, mobile app backends, RESTful APIs, and more. It is designed to help solve many of the problems faced by web developers by focusing on delivering a web service in a cloud service.
The App Service provides the features and frameworks needed to build, deploy, and maintain enterprise-class applications. You can use many popular development platforms and languages, such as Java, PHP, Node.js, Python, and the Microsoft .NET Framework.
By default, when you enable the App Service in Azure Stack, it creates the following infrastructure for you:
- Website driver: This role server is responsible for creating and managing roles for other services.
- Management: This role is the App Service REST API used by Azure Stack.
- Front end: This role accepts incoming HTTP / HTTPS requests from web application consumers, directs the request to the employee’s server where the web application is running, and returns responses from the employee to the client.
- publisher: This role is responsible for publishing content created by DevOps to web applications. It is an FTP (File Transfer Protocol) endpoint and is responsible for integration with code repositories such as GitHub.
- Employee (shared mode): This role is responsible for running the web application that the client connects to.
- File server: This saves the content of each web application downloaded to the application service. Employee roles acquire the necessary files for the web application from this role.
These instances can be scaled to meet the requirements of the App Service Resource Provider. For more information about Azure Stack’s App Service Resource Provider: check out the following article.
One day, I was preparing to deploy an App Service resource provider in Azure Stack Integrated Systems, and I went through all conditions steps before I start the actual deployment.
Since this is a production use, it is recommended and important to install the App Service as a highly available configuration. Otherwise, the service may be disabled if any of the components fail. For more information on HA deployment in the App Service: check the following guide.
After the HA deployment was successful, I was able to launch the App Service from the Admin Dashboard.
After a few days, however, the dashboard no longer opened, and I received the following error message:
The App Service plug-in failed to load. Check to see if the App Service resource provider and sql database are running.
As part of the highly available deployment of virtual machines in the App Service infrastructure, the following resources will be created:
- Virtual network and required subnets.
- Network security groups for file server, SQL Server, and Active Directory Domain Services (AD DS) subnets.
- Storage accounts for VMs and cluster cloud witnesses.
- One internal load balancing for SQL virtual machines whose private IP is bound to the SQL AlwaysOn listener.
- Three usability sets for AD DS, file server cluster, and SQL cluster.
- A two-node SQL cluster.
- A two-node file server cluster (Storage Spaces Direct).
- Two domain controllers.
Because it is a very available deployment, I went to the virtual machines card and restarted one SQL server node.
After a few minutes, I returned to the App Service dashboard and noticed that the dashboard is charging now!
So it seems that the problem is related to the App Service SQL database.
I went back to implementing HA document here and I re-read the instructions to see if I missed any steps. I found that at the end of the document there is a user comment that he is hitting the same problem and stating the following:
in Post-deployment steps, Microsoft states:
As you can see, the document is misleading and the steps are not properly documented.
As you type this issue, after you install this service, you must go to SQL Server, back up the two databases, and then add them to the Availability group. do this, the databases will not be available if the listener in the Availability group moves to another SQL node. Therefore, the App Service plug-in will not load.
To resolve this issue, follow these steps:
- Open a remote desktop session CN0-VM (with a public IP address). But before you do, you have to Add an inbound RDP port rule in the Network Security Group (NSG) to allow access to this virtual machine because RDP access is blocked from the Internet by default. Note that you must useOther Roles Virtual Machine Administrator username and password ”for login.
- From CN0-VM, you must open another RDP session for one of the SQL Server clusters. Note that you must use the domain administrator username and password for the domain controller that will be deployed as part of the App Service infrastructure.
- Start SQL Server Management Studio (SSMS) and connect to both SQL servers at the same time. At this point, you should see that one SQL Server has two application service databases and one server does not.
- Right-click each database (appservice_hosting and appservice_metering) and then select Tasks -> Back up… And continue next through the wizard. This step is optional, but better safe than sorry!
- Once the databases have been backed up, open Always high availability groups on both servers and find out which server it is (Primary).
- Right-click alwayson-ag (primary) and select Add database …
- Choose these two App Service Databases and click Next> continue.
- in Connect to existing secondary copies Click Connect… connects to a secondary replica SQL Server. Click Next> continue.
- in Select Initial Data Sync step, keep the default setting Automatic sowing and click Next> continue.
- in Confirmation Step, make sure all the results have passed successfully, and click Next> continue.
- in Summary step, check the selections you made in the wizard and click Finish.
- In the last step, check wizard completed successfullyand click Closed.
- That’s what you have. The databases are now on both SQL servers. In this example SQL-1 is Primary.
- If one server is restarted or down, the application service remains available to users ( Secondary server unavailable – as expected), Primary the server is only active. In this example SQL-0 is Primary now.
- Last but not least, don’t forget to delete and delete the RDP access rule you set. CN0-VM (NSG) in Step 1.
Thanks to the Azure Stack team for helping me get to the bottom of this.
Hope this helps someone out there!
Thanks for locking my blog.
If you have any questions or feedback, please leave a comment.