Tag: Sitecore Managed Cloud

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!!!!

Advertisement

New/Existing Domain as Custom Domain in Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As a part of Sitecore Managed Cloud series this one is last article about adding New or Existing domain to SMC app services.

So let’s start directly on article which tells us, how you can migrate the New/existing domain to your SMC Azure App Service as Custom domain.

Enable the CNAME record mapping in Azure

In the left navigation of the app page in the Azure portal, select Custom domains.

Custom domain menu

In the Custom domains page of the app, add the fully qualified custom DNS name (www.contoso.com) to the list.

Select the + icon next to Add custom domain.

Add host name

Type the fully qualified domain name that you added a CNAME record for, such as www.contoso.com.

Select Validate.

The Add custom domain page is shown.

Make sure that Hostname record type is set to CNAME (www.example.com or any subdomain).

Select Add custom domain.

Add DNS name to the app

It might take some time for the new custom domain to be reflected in the app’s Custom domains page. Try refreshing the browser to update the data.

CNAME record added

Note:

After you added custom domain don’t forget to add this domain entry in to sites configurations in SiteDefinition.config or Sitecore.config files.

Happy Learning!!!!

Disaster Recovery in Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I will explain DR or considering High Availability options in Sitecore Managed Cloud. So without doing any delay, we are going to touch straight to the point and start with a process for recovering your data in the event of an outage, incorporating:

  1. Backup technology
  2. Your secondary environment
  3. The steps of the recovery process
  4. Cost
  5. The recovery point objective (RPO)
  6. The recovery time objective (RTO)

Sitecore Managed Cloud offers three different disaster recovery options that differ slightly in cost and specifications, depending on your requirements. The recovery options available are:

  1. HADR Basic
  2. HADR Hot-warm
  3. HADR Hot-hot

Before we go into an explanation of the above three option, I want to explain basic terminologies in the Sitecore high availability disaster recovery (HADR):

  1. High availability (HA) – A system that aims to ensure an agreed level of operational performance. Usually, the uptime is higher than for the normal period, where the system can failover by itself.
  2. Disaster recovery (DR) – An area of business continuity planning that aims to protect an organization from the effects of significant negative events. Disaster recovery allows an organization to maintain or quickly resume mission-critical functions following a disaster that requires manual intervention.

Now I will explain all three options mentioned above, on a high level one by one as below.

HADR Basic:

With HADR basic, the Sitecore Managed Cloud disaster recovery service sets a process into action in the event of an outage. The steps of this process include:

  1. Scheduling a reoccurring backup, that occurs every 3 hours, of the following assets into the secondary database of the recovery point objective (RPO):
    • The databases.
    • Web applications.
    • The connection strings, (for the credentials).
    • The sizes/tiers of the resources.
  2. Arranging an outage page for customers to see while your site is down.
  3. Setting the traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
  4. Setting up email alerts to notify the Managed Cloud Operations team if the availability tests fail.

HADR Hot-warm:

If you are using the HADR hot-warm option, in the event of an outage the Sitecore Managed Cloud disaster recovery service sets the following process into action:

  1. Deploy a new Sitecore environment in the secondary data center and shut down your web applications.
  2. Use active geo-replication to sync the data between the primary and secondary Azure SQL.
  3. Sync the sizes/tiers of all your Azure resources.
  4. Sync the file contents of all of your web applications.
  5. Set up an outage page to ensure your customers are aware that your site is temporarily down.
  6. Set up a traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
  7. Set up email alerts to notify the Managed Cloud Operations team whenever an availability test fails.

HADR Hot-hot:

In the event of an outage, with the HADR hot-hot option, you must set into motion a recovery a process that is similar to the following:

  1. Enable recovery during a disaster by setting up the necessary environment before the disaster happens.
  2. Initiate the backup and replication process so that the Sitecore deployment and data are available for a healthy recovery.
  3. Deploy a passive Sitecore solution into the secondary region.
  4. Set up and enable the traffic manager to be the public gateway.

Prerequisites:

To set up your disaster recovery process:

  1. Ensure you are running your Sitecore solution (9.1 or later), on Azure.
  2. Install PowerShell with an Azure SDK, version 6.0.0 or later.
  3. Run your setup script and use the relevant modules.
  4. Use PowerShell (AzureRM), to log in to Azure and select the relevant subscription.
  5. Have your Sitecore license file ready.
  6. Have any scripts that you want to develop for your HADR hot-hot scenario ready.
  7. Use the Sitecore Azure Toolkit.

Note:

  1. Sitecore supports the following topologies: XM and XP, and the following deployment sizes: Extra Small, Small, Medium, Large, Extra Large.
  2. You can also use Simple Azure PaaS DR management to create DR of your SMC instances.

Reference:

https://doc.sitecore.com/developers/91/sitecore-experience-manager/en/high-availability-disaster-recovery–hadr-.html

Happy Learning !!!!

Deploying to Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As part of of Sitecore Managed Cloud blog series this my last blog for how to deploy to Sitecore Managed Cloud.

Without any further delay I will start with option which we have to deploy to SMC.

  1. Sitecore Azure Toolkit (SAT).
  2. Use Azure DevOps with TDS and Razl.

Sitecore Azure Toolkit (SAT):

To deploy your Sitecore solution onto Microsoft Azure®. The Sitecore Azure Toolkit simplifies the task of preparing and deploying a Sitecore solution with:

  • PowerShell commandlets to package a Sitecore instance into role-specific packages.
  • Default integration with Microsoft Azure services: Microsoft Azure SQL®, Microsoft Azure Redis Cache, Microsoft Application Insights®, Microsoft Azure Cognitive Search®.
  • Prebuilt ARM templates for frequently used topologies: XM, XP, XPSingle.
  • Configuration tweaks to run Sitecore on the Azure App Service.
  • Security features: HTTPS, low-privileged SQL access, secure Sitecore password.

Click here for more documentation for  getting started with Sitecore Azure Toolkit.

Use Azure DevOps with TDS and Razl:

There is another way which can be used is Configuring CI-CD pipelines in Azure DevOps by Using TDS web deploy packages. And for migrating the database use a Razl for first time. Let me explain this to you steps by step.

  1. Once you get SMC environments to use, you need to raise a ticket to Sitecore support for providing a services contract details for Azure DevOps which you are using.
  2. Once you get those details you need to configure that in your Azure DevOps account.
  3. Once Above is done you can use TDS to build and create web deploy packages pipeline.
  4. Once build pipeline is created then you can go further and create a release pipeline for the same.
  5. Now once entire setup is done you can have two option for getting your content (Sitecore data) migrated. The simple way is to sync everything to TDS and deploy, and the best way(recommended) is that use Razl to Sync all data for first time and then in subsequent release sync only required Sitecore data to TDS.

Summary: I found two ways to deploy the solution on SMC, but there are many different ways to do this. Please let me know in comment the other ways you guys used for deploying Sitecore on SMC.

Note: For using Razl please click here for link where great way described by Jon Jones.

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!!!!

Role and Responsibilities in Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As per last blog of this series of Sitecore Manged Cloud concept we will start next topic which is Roles and Responsibilities in working with Sitecore Managed Cloud. Below are the roles involved in implementation of Sitecore Managed Cloud.

  1. Sitecore
  2. Sitecore Partner
  3. Sitecore Customer

Now we will straight away move to responsibilities of each role in different streams.

Sitecore(Sales and Cloud Ops team):

once Sitecore sales team on-board you with below process there most of the work is done and and the only Cloud Ops team is the major contact point for you as Customer or Partner.

End-to-end

After setting up everything for you(Customer or Partner) access is given and then you(Customer or Partner) need to deploy your solution to the Sitecore Managed Cloud environment. There are few other responsibilities like below.

  1. Infrastructure Monitoring.
  2. Application Security.
  3. Proactive Infra incident notifications.
  4. Web app firewall configurations.
  5. Web app scale up process.
  6. Database backup service.
  7. Initial SSL configurations.
  8. Actions on infra suggestion.
  9. Security incident management.
  10. Activation and termination of cloud service .
  11. Billing.
  12. Process monitoring.

Sitecore Partner/Customer:

Sitecore Partner/Customer has many responsibilities like below.

  1. Deploy Solution on Sitecore Managed Cloud.
  2. Network: NSG and Firewall setup.
  3. Third party service connectivity.
  4. SSL configurations.
  5. Sitecore platform hotfix management.
  6. Custom domain setup.
  7. Sitecore version upgrade.
  8. Performance optimization

There are so many other responisiblities are there in this process for Customers/Partner and Sitecore, I have listed only the major ones. you can learn more at Sitecore Managed Cloud doc.

Hope above will help you, I will be continuing posting article for this series.

Happy learning.

Getting started with Sitecore Managed Cloud

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Earlier I shared a blog where we discussed working with Sitecore Managed Cloud.

Let’s directly get into the business this could be a series of blogs for Sitecore Managed Cloud, particularly divided into three parts.

  1. Responsibilities.
  2. Capacity Management.
  3. Deploy on Managed Cloud.

We will discuss this introductory part in points as below.

  • Sitecore Managed Cloud comes with two offerings same as Azure as follows.
    1. Standard: Sitecore provides customers with a base-level infrastructure hosting capability and basic product support with industry-standard uptime.
    2. Premium: Sitecore, in partnership with a third-party provider, delivers extensive coverage. This includes advanced infrastructure services for customers with more demanding operational support and security needs.
  • Before implementing Sitecore Managed Cloud you need to work on below bullet points.
    1. Formal understanding of Sitecore Managed Cloud services offered.
    2. Sitecore Managed Cloud services catalog.
    3. Training on Sitecore Managed Cloud.
    4. A healthy understanding of Azure especially Azure PaaS.
    5. Understanding the RACI matrix.
    6. Understanding different behaviors on the Sitecore XP platform on Azure PaaS.
    7. Azure Search.
    8. SolrCloud(SearchStax).
  • Sitecore Managed Cloud comes with 6 different topologies as below.
    1. XP Single
    2. XP Scaled
    3. XM Single
    4. XM Scaled
    5. xDB Single
    6. xDB Scaled
  • Working with topologies.

It is highly recommended that as a customer or Sitecore Partner you should decide infrastructure strategy(topology/tier) in consultation with the Sitecore Managed Cloud team. Because here Sitecore Managed Cloud team helps you to decide the topology and tier of infrastructure by getting details on a few predefined questions, this what they call capacity planning of Sitecore Managed Cloud. Here, in this case, the Sitecore sales team plays a crucial role to help for connecting everyone and get this decision done.

  • What access and Permissions you will get.
    1. Full access a contributor to the Azure Platform.
    2. Full access to all Sitecore instance s and app services.
    3. Full access to deploy custom code.
    4. Support for XP, XM,xDB.
    5. Compatibility for On-Premises environments.
  • Tranings.

The last part of this introductory overview blog is training. There is a training available for both Customers and Partners, you need to follow below for getting started with training.

To enroll in Managed Cloud training,

      1. Go to sitecore.com
      2. For Customers, click Sitecore Training.
      3. On the Sitecore training and support page there are a number of training options available:
        • Instructor-led training – Click on a region near you to enroll in the classroom or virtual instructor-led training sessions.
        • Online training – Sign up for an eCourse.
        • Certifications – After you have completed your training, you can sign up to become a certified Sitecore Developer.

Happy Learning

Globalization Setting Sitecore PaaS and SMC

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to give you quick quick learning details about how you can setup default Culture of your Sitecore Application.

First question which will get raised why you want set  this?(specifically in Azure PaaS and Sitecore Managed Cloud)

Answer to this question is now a days we host Sitecore application in Azure PaaS or any Other Cloud offerings where the actual Timezone and Culture is different. In this case the impacts will come to few part off your application where your using default culture settings in application globalization. Which means miss match of time/date formats etc.

Next question will be How we can fix it ?

So the answer is as below.

  1. Go to your Sitecore application.
  2. Open Web.config.
  3. Serch for below term.                                                                                          “<globalization”
  4. You will find a predefined setting with few attributes but you can set few more attributes like below to set default Culture of your application.
<globalization requestEncoding="utf-8" responseEncoding="utf-8" enableClientBasedCulture="false" culture="en-GB" uiCulture="en-GB" />

Note:

  1. This setting is totally different than the Time Zone setting for Sitecore application.
  2. What I mean over here is even if you set Time Zone to the one which you want in Cloud still you will get issues with formats.
  3. So this settings will help all those issues in Sitecore.
  4. This settings is tested of in Azure PaaS and Sitecore Managed Cloud.

Happy Learning

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.