App Service Tips in TP2 Refresh 1

Monday , 23, January 2017 Leave a comment

Brief Overview

The App Service Resource Provider in Azure Stack offers the same deployment and management experience for Web, Mobile, and API apps as is available in Public Azure, while also extending the provider with capabilities which are unique to Azure Stack.

In addition to the expected Azure consistent capabilities, the App Service in Azure Stack allows customisation of shared and dedicated web worker VMs which host tenant applications, as well as the associated pricing SKUs, in order to most efficiently meet the needs of on-premises and hosted customers, both computationally and financially.

Worker Tiers 
MgmtSvcCIoud 
Add Refresh 
Shared Worker Tiers 
NAME 
Shared 
CORES 
MEMORY 
1792 
MEMORY 
1024 
2048 
4096 
8192 
QUANTITY 
Windows Se 
Dedicated Worker Tiers 
NAME 
Small 
Medium 
Large 
Supreme 
CORES 
2 
4 
8 
Wi dows 
Wi n dows 
Wi n dows 
Wi n dows 
Server 2012 R2 
Server 2012 
Server 2012 R2 
Server 2012 R2 
o 
o 
10 
AVA' LABLE 
AVAILABLE 
o 
10

Azure Stack administrators can deploy multiple shared worker instances, and define and deploy multiple different tiers of worker which do not exist in Public Azure. Different worker instances can have different core and memory counts, different operating systems, and custom software available.

The ability to deploy custom software is unique to Azure Stack and is not available within Public Azure, where you are limited to pre-defined options. Custom software can be made available for deployment via MSI, Zip, Exe, or DLL, and is packaged for consumption within custom worker tiers.

Create New Custom So... 
X Discard 
* Product Id 
p H pNuke 
Title 0 
Version O 
Installer Type O 
Installer (Msi) 
Package (Zip) 
Executable (Exe) 
Lib ra (D Il) 
Target Directory O 
Install Executable O 
Install Arguments O

In true PaaS fashion, these capabilities and the underlying compute resources are abstracted away from tenants and presented as easy to digest SKUs, which are again fully customisable to an Azure Stack admin’s customer requirements.

SKUs 
Mg mtSvcCIoud 
Add 
Free 
Shared 
Sta n d a rd 
High 
X 
3 
High 
SKU 
Discard 
* Name O 
Color Card O 
Green 
Compute Mode O 
Dedicated 
Worker Tiers O 
Large 
Features 
Qu otas 
X 
Refresh 
MODE 
Shared 
Shared 
Dedicated 
Dedicated 
Disable 
COLOR CARD 
Orange 
Orchid 
Blue 
Gree n 
COLOR CARD 
SKU Features 
X Discard 
Web Sockets O 
Custom Domains 
Off 
Ip Based SSI Mode O 
Off 
SNI 
SNI & IPv4 SSL 
SNI & IPv6 SSL SNI & IP SSL 
Worker process 64 bit as default 
Disabled SKUs 
MODE 
No SKUs defined. 
On 
Off 
Worker Process 64 bit Enabled O 
Off 
App Concurrent Request Limit O 
5000 
Site Cpu Percentage Limit O 
Site Memory Lit-nit (VIE) O 
1024 
Site Memory Working Set Limit (MB) O 
1024 
Site Idle Timeout (Minutes) O 
10080

Notes from Testing in Azure Stack TP2 Refresh 1

Hardware in operation:

Dell R630 13G Server

2x 10 Core E5-2650 Processors

384GB RAM

2x 800GB SSD, 6x 1.2TB 15k HDD

Deployment of Web Workers

  • Ten Large Web Workers were deployed concurrently to test deployment process and time to complete. While the deployment ultimately succeeded, the technical preview limitations of (SSD backed) Azure Stack storage for more than a single operation became apparent through this process, with deployment taking over 62 hours to complete.
  • After completing, the Status of the Web Worker Instances can occasionally change from Ready to Installing – consoling onto the VMs shows that this is due to installation of Windows Updates. Due to the insanely slow storage access with this many VMs running, in the Roles with only a single instance, this had the effect of taking that instance offline on a regular basis as the tier becomes unavailable due to insufficient Ready Instances.

Large Web Worker Instances 
Repair All 
NAME 
10.02.13 
10.0.2.18 
10.0.2.10 
10.0.2.11 
10.0.2.19 
10.02.15 
10.02.12 
10.0.2.14 
10.0.2.17 
10.0.2.16 
PLATFORM VERSION 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
STATUS 
Ready 
Installing 
Installing 
Installing 
Ready 
Ready 
Ready 
Ready 
Ready 
Installing
Shared Web Worker Instances 
Repair All 
NAME 
10.0.2.4 
PLATFORM VERSION 
57.0.10696.7 
STATUS 
Installing
Updating your system (96%)

  • Following one Windows update, the Shared Instance Web Worker VM came back up without a NIC, however its VM is definitely configured with a NIC.

Not connected - No connections are available 
1/23/2017
Network Connections 
Network and Internet Network Connections 
Organize 
This folder is empty.
Settings for e9038d1 b-bec9-426d-b9cf 
e9038d1 b- bec9-426d-b9cf-e851 bd6551 v 
Hardware 
r Add Hardware 
BIOS 
Boot from CD 
Security 
Key Storage Drive disabled 
Memory 
1792 Ma 
æ_] Processor 
1 Virtual processor 
E] IDE Controller O 
Hard Drive 
IDE Controller 1 
DVD Drive 
None 
SCSI controller 
00 IDD8B71C06 
SdnS',Nitch 
Hardware Acceleration 
Advanced Features 
e851 bd655138 on ASHOST 
Netvvork Adapter 
Specify the configuration of the netw•ork adapter or remove the netv•ork adapter. 
Virtual switch: 
SdnSwitch 
Enable virtual LAN identfication 
The VLAN identfier specifies the virtual LAN that this virtual machine will use for all 
net',xork communications through this net',xork adapter 
Bandwidth Management 
Enable bandwidth management 
Specify ho•A' this network adapter utilizes network band'"idth, Both Minimum 
aand'A'idth and Maximum aand',vidth are measured in Megabits per second. 
Minimum bandwidth : 
Maximum bandh'idth: 
O 
O 
Mbps 
Mbps

  • Running a Repair All on the Instance from within the Azure Stack portal did not resolve this.
  • Leaving the VM for >24 hours did not resolve this.
  • Manually rebooting the VM did resolve this.

 

One of the ten Web Workers (WW3) took significantly longer than the others to deploy – around 25 minutes extra, which is probably not an issue but just noting it for rigour The first nine VMs deployed in 45 minutes, with WW3 finishing after 70 minutes.
Operation details 
RESOURCE 
WW4-VM/OnStart 
WW2-VM/OnStart 
WW6-VM/OnStart 
WW7-VM/OnStart 
WW1 -VM/OnStart 
WW5-VM/OnStart 
WW9-VM/OnStart 
WW8-VM/OnStart 
WWIO-VM/OnStart 
WW3-VM 
WW2-VM 
WW6-VM 
TYPE 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
Microsoft.Compute... 
STATUS 
Created 
Created 
Created 
Created 
Created 
OK 
OK 
OK 
OK 
Created 
OK 
OK 
TIMESTAMP 
2017-01-20T21 
2017-01-20T21 
2017-01-20T21 
2017-01-20T21 
2017-01-20T21
Specs for a Large Web Worker are 4 Core, 4 GB RAM, however all Large Web Workers deployed at Shared instance specs of 1 Core, 1.75GB RAM. This repeated when deploying a custom Web Worker of 8 Cores, 8GB RAM. All Web Workers in TP2 Refresh 1 deploy at Shared tier spec for now it seems.
08 
08 
08 
08 
08 
08 
08 
•••!1e4n6uu03 
srueas 
80€L ZZZ 
OBSO LOZ 
LOZ 
LOZ 
fi LB LOZ 
LEGSOOZ 
9760 LOZ 
awgdn 
Z6LL 
ZSLL 
Z6LL 
ZSLL 
Z6LL 
an ZSLL 
Z6LL 
ZSLL 
Z6LL 
ZSLL 
Z6LL 
Lo Luan pau6!ssv 
BLI!uur1H 
5u1uunH 
BLI!uurre 
BLI!uurrH 
BLI!uurrH 
5u1uurrH 
ôuluure 
aEesn n dû 
L ïq-sesv-ttsz-ss LLZûtS 
"'te•08L7-SLSL-LZS8LOLt 
L -OZSZOOE 
• •ytve-G067-ape-9-somqsa 
- es26-00h-8€zq-eqp€m€q 
•••q-eot7-tesz-zLGLqqae 
--0L6-6q•osqa-9L9L602È 
a LueN 
lenu!A

  • Deleting a Web Worker Role from the Azure Stack Portal does not currently remove the underlying Virtual Machine from the Infrastructure.

Role Repair

  • Repair of all roles works as expected, other than on the controller instance which fails with the following error:

    • Code: 400, Message: Role object is not present in the request body.
  • I am currently unaware of a fix for this, or indeed even if one is needed or available.

Controller Instances 
Repair All 
NAME 
10.0.2.6 
O Repair instances 
x 
10:30 PM 
Repair 1 instance(s) failed. Reason: Client error occured. Code: 
400, Message: Role object is not present in the request body. 
PLATFORM VERSION 
57.0.10696.7 
STATUS 
Ready

Deployment of a WebApp

Most WebApp deployments succeed as expected, however there are instances where it has failed.

  • During the below deployment of a new WebApp to a dedicated instance, an error was thrown – Conflict error: Not enough available reserved instance servers to satisfy this request. Currently 0 instances are available.

Microsoft.WebSite08f9395c-9acd 
Deployment 
Delete Cancel Refresh 
Lt.] Redeploy 
Failed. Click here for details 
"Code": "Conflict" 
X 
View template 
RELATED 
Outputs 
NO DEPLOYMENT OUTPUTS 
Inputs 
NAME 
HOSTINGPLANNAME 
HOSTINGENVIRONMENT 
LOCATION 
SKU 
WORKERSIZE 
SERVERFARMRESOURCEGROUP 
SUBSCRIPTIONID 
Operation details 
RESOURCE 
dedicated 
Events 
dedicated 
local 
Standard 
2 
dedicated 
8145fe3d%27e4c12Æb39S7878275b703 
Operation details 
OPERATION ID 
TRACKING ID 
STATUS 
PROVISIONING STATE 
TIMESTAMP 
DURATION 
TYPE 
RESOURCE ID 
STATUSMESSAGE 
TYPE 
Microsoft.Web/serv... 
STATUS 
Conflict 
TIMESTAMP 
2017 
938E6474AB3EF62A 
3e87c883-1 c36-43c6-a5ae-4275a40c2988 
Conflict 
Failed 
1/23/2017 2:30:55 PM 
7 seconds 
Microsoft. Web/serverfarms 
/subscriptions/8145fe3d-b27e-4c12-8b39-57878275b703/reso... 
"Code": "Conflict", 
"Message": "Not enough available reserved instance servers to 
satisw this request. Currently O instances are available. If you are 
changing instance size you can reserve up to O instances at this 
moment. If you are increasing instance count then you can add 
extra O instances at this moment." 
"Target": null, 
"Details": 
"Message": "Not enough available reserved instance setvers 
to satisfy this request. Currently O instances are available. If you 
are changing instance size you can reserve up to O instances at 
this moment. If you are increasing instance count then you can 
add extra O instances at this moment." 
"ErrorEntity": { 
"Code": "Conflict", 
"Message": "Not enough available reserved instance servers 
to satisfy this request. Currently O instances are available. If you

  • Two thoughts as to why this could happen were:

    • All Web Worker Instances were undergoing updates at the same time
    • All Web Worker Instances had sites running on them, and as they are dedicated there are none free

Only one Instance was updating at the time, deleting it to bring all Instances to a Ready state had no impact, the deployment still failed.

Large Web Worker Instances 
Repair All 
NAME 
10.0.2.13 
10.02.19 
10.0.2.15 
10.0.2.12 
10.0.2.14 
10.0.2.17 
PLATFORM VERSION 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
STATUS 
Ready 
Ready 
Installing 
Ready 
Ready 
Ready

The Admin portal reports that none of the Instances have any running sites on them, which should make them available for placement…

Large Web Worker Instances 
x 
Repair All 
NAME 
10.0.2.13 
10.0.2.19 
10.0.2.12 
10.0.2.14 
10.0.2.17 
STATUS 
Ready 
Ready 
Ready 
Ready 
Ready 
10.0.2.17 
Large Web Worker 
Repair 
Essentials 
Narne 
10.0.2.17 
Worker Tier 
Large 
Running Sites 
o 
Custom Software 
Not defined 
Instance 
1:45 PM 
CPU 
Http 
Stop 
Logs 
PLATFORM VERSION 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
57.0.10696.7 
Delete 
2 PM 
Role 
Web Worker 
Compute Mode 
Dedicated 
Allocated Dedicated Worker 
No 
2-15 PM 
DISK QUEUE LENGTH 
Add tiles 
2:30 PM 
HI-rp QUEUE LENGTH 
146 
MEMORY PERCENTAGE

… however, there are in fact currently two webapps deployed in the Dedicated Large tier, and another in the Shared tier, and not a single instance is reporting any WebApps deployed into them.

Conclusion: The Admin Portal does not accurately report the number of running WebApps in an instance yet, and all of the dedicated instances were indeed in use at this time.

Backup of WebApp

When configuring the Storage for backup of a WebApp, I accidentally left the storage endpoint as core.windows.net rather than specifying the local Azure Stack endpoint. This naturally caused the backup to fail. After correcting the issue, backups still failed for ~10 minutes as it believed an existing backup is in progress.

Once the infrastructure timed out the initial backup, subsequent backups to Azure Stack storage were able to proceed as expected, and completed successfully.

Backup Configuration Summary 
Backup configured properly with a Schedule to backup your site every 1 days. Last 
backup happened on Monday, January 23, 2017 1:14:47 PM. 
L. 
Schedule: Configured 
Storage: Configured 
All backups 
STATUS 
••/ Succeeded 
BACKUP TIME 
1/23/2017 1:14 PM 
SIZE (MB) 
0.12 
LAST RESTORED

Scale Up of an App Service Plan

Initial testing of Scale Up of an App Service Plan failed with a non-specific error.

Microsoft Azure Stack 
Failed to update App Service plan 
Failed to update App Service plan 
> 
Detail 
klowe@bl 
X 
DESCRIPTION 
STATUS 
TIME 
CORRELATION IDS 
EVENT 
Failed to update App Ser... 
Failed to update App Service plan klappspl: 
error has occurred. 
Error 
Monday, January 23, 2017 1 - 
.09:16 PM 
4e1be96d 0826 40b3-a852 21 164552d8eb 
Detail 
TITLE 
DESCRIPTION 
STATUS 
TIMESTAMP 
UTC TIMESTAMP 
CORRELATION IDS 
Failed to update App Service plan 
Failed to update App Service plan klappspl: {"Message"•"An 
error has occurred." ) 
Error 
Mon Jan 23 2017 GMT+OOOO (GMT Standard Time) 
Mon, 23 Jan 2017 GMT 
421 be96d-082640b3-a852-21164552d8eb 
LEVEL 
O Error 
STATUS 
Error 
TIME 
Jus...

Deploying a new WebApp and testing scale up of it worked as expected, so cause of the initial failure is currently unknown.

Scale Out of an App Service

Initial test of Scale Out of an App Service fails with an error ‘Failed to save scale settings’.

Saving scale settings 
DESCRIPTION 
STATUS 
TIME 
CORRELATION IDS 
EVENT 
Saving scale settings 
Failed to save scale settings. 
Error 
Monday, January 23, 2017 1:33 PM 
clientNotification Idb7feOa a66d 4bbe a47b 
dd2e956bf02e 
LEVEL 
O Error 
STATUS 
Error 
TIME 
Jus...

As with Scale Up, creating a new WebApp resolved this as well and Scale Out reported as completing successfully.

All other tests/integrations currently tried worked as expected. For completeness, these are:

  • Deploy the App Service RP
  • Add the App Service RP to Azure Stack
  • Create custom SKUs
  • Configure Source Control Providers (GitHub only)
  • Custom DNS Integration
  • Create an App Service Plan
  • Create an Empty Website (using custom SKU utilising custom Web Worker tier)
  • Deploy an existing Web App into App Service

    • For this I used a Bot for Dynamics CRM which I had previously created using the Microsoft Bot Framework. As this Azure Stack instance doesn’t have an externally available URL/IP I wasn’t able to test it connected through to Dynamics CRM, however deployment succeeded as expected.
    • Note: Microsoft should have called the Bot Framework the Bot Net Framework.

Leave a Reply

%d bloggers like this: