Tag: Azure

How to enable Profiler in Azure App Service

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to explain how we can enable profiler in Azure App Service. Below are the details to enable Profiler.

Enable Profiler for your app

To enable Profiler for an app, follow the instructions below. If you’re running a different type of Azure service, here are instructions for enabling Profiler on other supported platforms:

Application Insights Profiler is pre-installed as part of the App Services runtime. The steps below will show you how to enable it for your App Service. Follow these steps even if you’ve included the App Insights SDK in your application at build time.

  1. Enable “Always On” setting for your app service. You can update the setting in the Configuration page of your App Service under General Settings.
  2. Go to the App Services pane in the Azure portal.
  3. Navigate to Settings > Application Insights pane.Enable App Insights on App Services portal
  4. Either follow the instructions on the pane to create a new resource or select an existing App Insights resource to monitor your app. Also make sure the Profiler is On. If your Application Insights resource is in a different subscription from your App Service, you can’t use this page to configure Application Insights. You can still do it manually though by creating the necessary app settings manually. The next section contains instructions for manually enabling Profiler.Add App Insights site extension
  5. Profiler is now enabled using an App Services App Setting.App Setting for Profiler

Happy Learning!!!

Advertisement

Azure worker reset module for Sitecore PaaS

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to introduce my new Module for Sitecore Azure PaaS. This module is called Azure Worker Exchanger details for this are as below.

What is Azure Worker Exchanger?

Azure Worker Exchanger Module is a facility created in association with Microsoft Azure Worker API to kill and replace any of the corrupt or non-performing workers created in Azure PaaS. This module should be used only when any worker process is showing a spike in performance and behaving abnormally or got corrupted, to analyze these below are the symptoms.

  1. Website loading slowly.
  2. Some of the users are not able to visit the website.
  3. Azure is throwing many alerts for performance issues.
  4. Azure matrics showing spikes for performance.

How to use this Module?

  1. Download the Module here.
  2. Install on CM role with Sitecore Package Installer.
  3. Once done you can navigate to the below URL to find the Form.
    https://yourdomain/InstanceExchanger.aspx
  4. Once the form is open you need to supply few details about your Azure Web app. (These are very simple and exactly as mentioned in below photo)
  5. Once you filled the form submit it.
  6. You will get a response message back.
  7. After that wait for 5-10 minutes for Azure to settle everything.
  8. Once everything is settled you need to go to the Azure Web app and open a kudu to see a new worker created with new underlying resources.

Happy Learning !! Keep Learning !!

Disabling ARR’s Instance Affinity in Sitecore Azure Websites

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to help you in different aspect of scaled environment in Azure where I will explain what is ARR in scaled Sitecore Azure instances. So without delaying we will start this with below pointer which will explain all the things related to this.

What is ARR Affinity?

Application Request Routing (ARR) is a feature where when a client (or browser) request to any Azure based website, a cookie will be created and stick to the first time request received web site instance.

The same cookie will be used for subsequent requests from this client or browser and these requests will be guided to the same web site instance the one which was served for the first time.

Advantages:
With this feature, we can get an advantage if in case the web site instance is maintaining lots of data in it’s memory and moving the subsequent requests to other instance leads to copy entire data to other instance and this is a more performance and pain to the system.

Dis-Advantages:
We can see many disadvantages when compared with advantages. If a client request and unfortunately the sticky instance is not available, this request cannot be guided to any other available instance instead it will send an unavailable message to the client.

Also, In case if an instance is a too much load with other request and this request will be in request queue instead can guide to other instance to balance the load.

How ARR Affinity works?

  1. Client connects to an Azure Web Sites website
  2. ARR runs on the front-end Azure server and receives the request
  3. ARR decides to which of the available instances the request should go
  4. ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request
  5. The response comes back to the client, holding the ARRAffinity cookie.
  6. When the client receives the request, it stores the cookie for later use (browsers are designed to do this for cookies they receive from servers)
  7. When the client submits a subsequent request, it includes the cookie in it
  8. When ARR receives the request, it sees the cookie, and decodes it.
  9. The decoded cookie holds the name of the instance that was used earlier, and so ARR forwards the request to the same instance, rather than choosing one from the pool
  10. The same thing (steps 7-9) repeat upon every subsequent request for the same site, until the user closes the browser, at which point the cookie is cleared
8407.blogpicture.png-550x0
 
This is how the affinity cookie looks:
 
5773.bp2.png-550x0
 

Disabling the affinity can be done in different ways: (Every one prefer that last way explained)

  1. In your application
    To control this behavior in an application, you need to write code to send out a special HTTP header, which will tell the Application Request Router to remove the affinity cookie. This header is Arr-Disable-Session-Affinity, and if you set it to true, ARR will strip out the cookie. For example, you could add a line similar to this to your applications’ code: 
     
    headers.Add(“Arr-Disable-Session-Affinity”, “True”);
     
  2. In a site configuration
    If you prefer to have it completely disabled, you could have ARR remove the cookie always by having IIS itself inject that header directly. This is done with a customHeaders configuration section in web.config. Simply add the following into your web.config, and upload it to the root of the site: 

6765.bp3.JPG-550x0 

There is one more way yo disable this is which require us to follow below steps.
  1. Go to Azure App service.
  2.  Then go to Configuration.
  3. In configurations you will find General settings tab click on it.
  4. Here in this tab you will find the Sections called Platform settings.
  5. In this sections you will find the ARR affinity radio button.
  6. As per requirement you can disable it.(by default this is on)

ARR

To test this you need to go into HTTP header and check the value is coming or not. Another simple way is once you disabled it you can clear your browser cookies and load the website again and check in cookies sections and you will find that ARR cookie is not created.

Happy Learning!!!!

Capacity Management in Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As out Sitecore Managed Cloud, series is going on. So I decided to get you guys a new informative blog for Capacity Management in Sitecore Managed Cloud and, without any due we will start this.

Following are some point which you as Customer or Partner needs to take care of in case of Capacity Management or Sizing in SMC.

  • Budget.
  • The size of your Content database
  • The size of your xDB database
  • Cache sizing
  • Your Search Engine implementation plan
  • Your disaster recovery plan
  • Your RPO and RTO in the event of an outage
  • Any Previous sizing references.

Role of Customer/Partner:

As a Customer or Partner, you can also share more and more analytics reports of your exiting application or forecast analysis of users and their behavior and application requirements with respect to infrastructure in Azure. As all this information will give the technical team a way to design a constructive way to implement your needs. 

You also need to specify special needs like if you want to integrate some services for log management(Sumo Logic), APMT(New Relic). because these can take extra storage, app services or databases.

Role of Sitecore Team:

Once you as Customer or Partner provides some prerequisite information from above at the time of availing this service, Sitecore Cloud Ops team will choose the tier accordingly and then give you vanilla instances of SMC. Once that is done then according to your Capacity plan which will be based on the rest of the remaining above point will be executed jointly as per roles and responsibilities decided.

Note: You always have to scale your capacities as all this is Azure PaaS based.

Happy Learning!!!!

Profiling a Sitecore Web App on Azure App Service

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to help you with how you can collect .NET Profiler Trace in Azure App Service. With out any further details we will jump in below details.

The Diagnostic Tools options under the Diagnose and Solve blade for Azure App Services has been live for a few months now and has many tools that help you troubleshoot apps based on their application stack. In this post, we are going to cover the Collect .NET Profiler Trace option in detail and how you can use it to troubleshoot a slow or a failing ASP.NET based Web App.  Profiler tool helps in collecting an on-demand trace that lets you identify the underlying .NET exceptions, time taken in the various request processing pipeline stages and even lets you drill down into exact methods within the application code that are taking time. It is extremely useful in situations where the problem is happening right now and you want to collect some data to identify the root cause of the issue. Profiling is designed for production scenarios and is based on ETW (Event tracing for Windows) . The analysis component of the profiler uses the TraceEvent library to generate a report that helps you drill down in to the problems in matter of a few minutes. It should be noted that no changes are made to your Web App code or your configuration during the collection or the analysis phase. In fact, the web app is not even restarted as a result of capturing this trace. The captured trace has ETW events emitted by the IIS and the ASP.NET providers along with stack traces captured at the CPU level. You can use this tool to efficiently troubleshoot delays which are relatively small (less than a second too) without impacting the run-time performance of the application. At this point, the profiler works only for ASP.NET web apps only and ASP.NET Core support might come soon.

How to Collect the Trace

To collect the trace, go to the App Service in your Azure PaaS, then go to  Diagnose and Solve Problems  and choose the Collect .NET Profiler Trace option under Diagnostic Tools option and click on Collect Profiler Trace. Unless you have isolated that only a specific instance is failing, it is best to just select all the instances on which your Web App is running.  Add thread report option – With this option enabled, a thread report of all the threads in the process is also collected at the end of the profiler trace. This is useful especially if you are troubleshooting totally hung processes, deadlocks or requests taking more than 60 seconds. This will pause your process for a few seconds until the thread dump is generated. This option is NOT recommended if you are experiencing high CPU on the instance because if the instance is under stress, it might take a long time to even start a new process to collect the thread dumps. Clicking the Collect Profiler Trace will start profiling the Web App and the wizard will show progress of various steps involved.  Once the profiler trace is started, reproduce the issue by browsing the Web App. If you have a Web App running on multiple instances, make sure to browse a few more times to ensure that the requests to the web app get captured in the profiler trace. The default duration for which the profiler trace runs is 60 seconds and during this 60 seconds, all the requests that were made to the Web App get captured in the profiler trace. It is important to note that the profiler trace only has information about the requests that were captured in these 60 seconds (It is possible to increase this duration as mentioned below in this article) After 60 seconds, the profiler automatically stops, and an analysis component gets triggered that starts analyzing the profiler trace that just got captured. After the analysis finishes, a link to view the profiler report for every instance serving the web app is generated and you click on the Open Report button to view the Analysis report. 

Happy Learning

Configuring Azure DevOp’s Release Pipeline for TDS

~ Nikhil Kulkarni ~ 2 Comments

Hi Champs,

In this part, we are configuring the settings in the Release pipeline to deploy our Web Deploy package. Although the deployment can also perform as part of the build, we prefer separate steps for build and deployment to reduce the chance of accidental deployments to production environments.

The Release pipeline takes the build artifacts from the Build pipeline and installs them on the Sitecore instances that have been configured in Azure. There are a couple of ways we can do this. We can use the generated PowerShell Script, or we can use some of the built-in settings in Azure DevOps. The PowerShell script can be modified to work within complex build processes, but the deployment can be accomplished even without it.

Deploy to Azure using the built-in Azure DevOps settings

Azure DevOps comes with a built-in App Service deploy task, taking the Web Deploy package from the Build pipeline and installs it in the selected Web App. Keep in mind, there are a couple of important configuration settings here. We need to add the Azure subscription where the Web App is located and select it under the Azure subscription tab. This fills out automatically as part of the settings, and you’ll only need to select your subscription and App Service.

Window of Azure App Service Deploy

Deploy to Azure using the generated PowerShell Script

The second way of deploying the Web Deploy package to the Azure Web App is using the PowerShell script generated by TDS Classic. This can be useful in build servers where there’s no native support for Azure Web deploy, or when the user wants full control and use their release script. The script also gives you an easy-to-read log containing the item names and location in the Sitecore tree of the items.

To use it, we need the Publish profile file, which can be added in source control and made available for the Release pipeline the same way we made available the PowerShell script and the Web Deploy package.

We also need to create a PowerShell Script task in our Release pipeline. In it, we specify the path to the PowerShell script, generated by TDS and the arguments, required for executing it. The arguments are the same as the ones we used for deploying from our development machine.

WIndow of Powershell

Both ways of deploying will give you status about the deployment and a log with all the details. The logs are formatted a bit differently, so consider this when choosing which method to use.

Window showing logs

Summary

With TDS 5.8, we had the goal to simplify the deployment of the TDS project to Azure environments. Using Web Deploy packages, we were also able to reduce the deployment time while making the process more intuitive and visible for the developers.

Missed Part Two? Click here to read how to configure Azure DevOp’s Build Pipeline.

Need to start from the beginning? Click here to read how to set everything up locally.

Also do check my blog for automating slot swapping in Azure DevOps.

Happy Learning

Configuring Azure DevOp’s Build Pipeline for TDS

~ Nikhil Kulkarni ~ 3 Comments

Hi Champs,

In part one, we set up our TDS project to create a Web Deploy package and published the package to an Azure App Service manually. Now that we know we can deploy our Web Deploy package from our local environment, let’s continue by setting up an automated build in Azure DevOps. In this part, we’ll configure only the steps in the Build Pipeline, and publish the build drop (a Web Deploy package and a PowerShell script) to the Release pipeline. Note that this is a simplified scenario to be used as a starting point. Your build/deployment process might be more complex and can include different steps than this one. 

Configure the Build Pipeline

For the build pipeline, we will build the project in the “Release” configuration being it is the configuration we set up for Web Deploy packages. The first step while creating your new Build pipeline is to select your repository settings. In this example, we will use Git.

Window to Select Repository

We also need to add the TDS license; otherwise, our build will fail. This happens in the Variables tab of your Build pipelines. The following variables should be created with your license info in the values.

As a starting template for our Build pipeline, we can use the Azure Web App for ASP.NET template. We don’t need all of the predefined build steps in the template for this example, so we will remove some of them. This is done to simplify the example and focus on the build process.

Window to choose a template

Our build will contain the following tasks in the Build pipeline:

Window of Build Pipeline

Summary of the Tasks

This summary explains each task and the most important thing we should configure:

Use NuGet
This task specifies the NuGet version the build server will use. We can leave it with the default settings.

NuGet restore
This task restores the NuGet package and also doesn’t require any special settings to be configured. 

Build solution
We will set the Build solution task to build the Release configuration. The Platform and the Configuration parameters are configured from the build variables. The default values are “Release” and “Any CPU” so we can use them directly.
Window to set Build Solution

Copy Files to
The next step copies the build output to the Staging directory, so it’s ready for publishing. We only need the PowerShell Script and the Web Deploy package from our build drop, so we will only copy them. Side Note: the paths might be different for your build. 

Window to Copy Files

Publish Artifacts
The final step in the Build pipeline is to publish the build artifacts to the next phase: the Release pipeline.

Window to publish the build artifacts

Once we have everything configured, we can run a test build. If everything is configured properly, we will see the Web Deploy package and the PowerShell script available in the Artifacts explorer in Azure DevOps.

Window of Artifacts Explorer

Summary

As shown above, setting up a build in Visual Studio online to create a Web Deploy package is relatively simple. The only real customization of the build was a step to pick up the files from the build folder and add them to the Artifacts folder. In the next part of the series, we will show you how to configure a release pipeline to deploy the Web Deploy package to an instance of Sitecore running on an Azure App Service.

Missed the first part? Click here to read Part 1.

Ready to continue to the next step? Click here to move on to Part 3.

Happy Learning

Higher thread usage in Sitecore Azure PaaS

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to explain one of the major factor which can contribute to issue of Performance to your Sitecore Application in Azure PaaS, which is excessive thread calls. Below are point wise explanation of entire case study with solution.

The actual trigger for Higher thread Usage: 

Calling an async code in a synchronous execution path leads to the calling thread being paused until the async part finishes (the corresponding Task object is marked as completed). Because of the specific implementation of async methods in C#, the Task object cannot be marked as complete until continuations are executed. In most of the scenarios, continuations are scheduled to be executed on thread pool threads. Therefore, the calling thread starts to depend on the availability of worker threads in the default thread pool.

One more contributor xConnect:

Sitecore xConnect is written according to high-performance application best practices, with optimized thread consumption. Its design allows for taking full advantage of async operation processing and it defines the custom scheduler to tackle excessive thread consumption.

So now you will be wondering that in regular development path we have both the above case will come, then why this issue started coming from Sitecore 9XP onward.

Simple answer(Root Cause of the issue):

Unfortunately, the recent changes in .NET Framework 4.7.2 (System.Net.Http assembly) removed the respect of custom thread schedulers. This has led to excessive thread consumption by sync-async operations.

Solution:

It is possible to configure a Sitecore application to use a previous version of the System.Net.Http.dll assembly instead of the .NET Framework 4.7.2 version.

Copy the System.Net.Http.dll file from the C:\Program Files (x86)\Microsoft Visual Studio\[*]\Professional\MSBuild\ Microsoft\Microsoft.NET.Build.Extensions\net471\lib folder to the \bin folder of Sitecore. Assembly file version 4.6.26011.01.

      – where [*] should be replaced with relevant Visual Studio version (2017 or 2019).

Configure Sitecore to use the new assembly version instead of the assembly from GAC:

  1. Remove all existing binding redirects for System.Net.Http from the Web.config file.
  2. Add the following binding redirect to the Web.config file: 
    <dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" xmlns="urn:schemas-microsoft-com:asm.v1" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />
</dependentAssembly>

When version 4.2.0.0 of System.Net.Http library is used, it contains an implementation of the HttpClient class that respects custom schedulers. Therefore, synchronous methods of xConnect client require just a single thread to complete a request.

Sumo Logic integration with Sitecore Azure PaaS

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to take you to the new product called Sumo Logic which we can integrate with Sitecore Azure PaaS for better log management.

Before starting you may have below two questions.

What is Sumo Logic?

Sumo Logic is a cloud-based machine data analytics company focusing on security, operations and BI use-cases. It provides log management and analytics services that leverage machine-generated big data to deliver real-time IT insights

Why Sumo Logic?

As per my experience Sumo Logic is coolest tool I ever seen for Log Management and monitoring. It gives a GUI based Live log management system by which you can track everything and not losing your time for checking logs from files. One more advantage is it alerts you one basis of exception captured in Log.

We will move without killing more time to the steps of configurations which are as below. Note all below steps you need to perform against your Sitecore Azure PaaS resource group.

Step 1. Configure Azure storage account

In this step you configure a storage account to which you will export monitoring data for your Azure service.

If you have a storage account with a container that you want to use for this purpose, make a note of its resource group, storage account name and container name and proceed to Step 2.

To configure an Azure storage account, do the following:

  1. Create a new storage account General-purpose v2 (GPv2) storage account. For instructions, see Create a storage account in Azure help.
  2. In the Azure portal, navigate to the storage account you just created (in the previous step).
  3. Select Blobs under Blob Service.
    Make a note of the container name, you will need to supply later in this procedure.

    1. Select + Container,
    2. Enter the Name
    3. Select Private for the Public Access Level.
    4. Click OK.

Step 2. Configure an HTTP source

In this step, you configure an HTTP source to receive logs from the Azure function.

  1. Select a hosted collector where you want to configure the HTTP source. If desired, create a new hosted collector, as described on Configure a Hosted Collector.
  2. Configure an HTTP source, as described on HTTP Logs and Metrics Source. Make a note of the URL for the source, you will need it in the next step.

Step 3. Configure Azure resources using ARM template

In this step, you use a Sumo-provided Azure Resource Manager (ARM) template to create an Event Hub, three Azure functions, Service Bus Queue, and a Storage Account.

  1. Download the blobreaderdeploy.json ARM template.
  2. Click Create a Resource, search for Template deployment in the Azure Portal, and then click Create.
  3. On the Custom deployment blade, click Build your own template in the editor.
  4. Copy the contents of the template and paste it into the editor window.
  5. Click Save.
  6. On the Custom deployment blade, do the following:
    1. Create a new Resource Group (recommended) or select an existing one.
    2. Choose Location.
    3. Set the values of the following parameters:
  • SumoEndpointURL: URL for the HTTP source you configured in Step 2 above.
  • StorageAccountName: Name of the storage account where  you are storing logs from Azure Service, that you configured in Step 1 above.
  • StorageAccountResourceGroupName: Name of the resource group of the storage account you configured in Step 1 above.
  • Filter Prefix (Optional): If you want to filter logs from a specific container, enter the following, replacing the variable with your container name: /blobServices/default/containers/<container_name>/
  1. Select the check box to agree to the terms and conditions, and then click Purchase.

Azure_Blob_Storage_Custom_Deployment.png

  1. Verify the deployment was successful by looking at Notifications at top right corner of Azure Portal.

notification-success.png

  1. (Optional) In the same window, click Go to resource group to verify the all resources were successfully created, such as shown in the following example:

Azure_Blob_all-resources.png

  1. Go to Storage accounts and search for sumobrlogs, then select sumobrlogs<random-string>.

storage-accounts.png

  1. Under Table Service do the following:
    1. Click Tables.
    2. Click + Table.
    3. For Name, enter FileOffsetMap.
  2. Click OK.

Azure_Blob_create-table.png

Step 4. Push logs from Azure Service to Azure Blob Storage

This section describes how to push logs from an Azure service to Azure Blob Storage by configuring Diagnostic Logs. The instructions use the Azure Web Apps Service as an example.

  1. Login to the Azure Portal.
  2. Click AppServices > Your Function App > Diagnostic Logs under Monitoring.
  3. You will see the Diagnostic Logs blade. Enable Application Logging, Web Server Logging, or both, and click Storage Settings.
  4. Select the Storage Account whose connection string you configured in Step 1.
  5. In the Containers blade, select the container you created in Step 1.
  6. In the Diagnostic Logs blade, specify the Retention Period (Days), and click Save to exit Diagnostic Logs configuration.export-webapp-logs.png

Happy learning and innovating Sitecore.

Automating Deployment Slot Swapping for Sitecore Azure PaaS

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Today I am going to introduce you to the steps which you can use to swap deployment slots for production environment automatically in release pipeline by small manual intervention for approval/resume. Below are the steps which will help you to set-up slot automation.

Given any scenario this will work, but in my case it is like below.

I have release pipeline stetted up according to the environments.

Configuring slot swaps in Production

The Dev and QA environments orchestrate whatever flow you want in those environments (e.g. provision using ARM, deploy, run functional tests, run load tests etc.), and in this example don’t have any slot specific activity. Therefore let’s take a look at the production environment tasks itself directly:

(I’ve kept this to a minimum to keep it clearer, so no provisioning, running scripts or other activities.)

First deploy the web application to the staging slot in the production environment using the Azure App Service Deploy task:

Check the Deploy to slot option in the standard task, and then choose the Slot (I called the slot “staging” but you can use any name).

Next I’ve added an Agentless phase as it’s not going to delegate any actions to an agent, and added a Manual Intervention task. This causes the flow to pause until the manual intervention is completed by the specified approvers (groups and/or individuals). If it’s approved then it carries on, if it’s rejected (or times out and therefore is rejected) then the flow stops. In this case that works for me as I want the staging environment to be manually verified and then signed off as ok for final release to production. If it gets rejected then it never gets promoted from staging to production.

Finally, if the staging slot has been manually verified and is ready to be used, then we can initiate the actual slot swap (in an agent phase) using the Azure App Service Manage task:

The staging and production slots will then be swapped over, leaving the old production version in the staging app and the latest version in the production slot.

This flow supports the actual slot swaps being automated, but with manual approval. A nice side effect of the slot swap is that should there be a problem, the slot swap can be reversed to redeploy (rollback) the old version of the app now in the staging slot.

Happy Learning/Innovating Azure.