Category: AWS

Setup Sitecore Databases in AWS RDS

On By Jeroen de GrootIn AWS, Containers, Sitecore 10Leave a comment

Last year Sitecore announced it supports AWS RDS. I’ve previously blogged about how to setup Sitecore databases in AWS using SIF. Containers are the preferred deployment model in Sitecore 10 now. A popular option when deploying Sitecore on AWS is to use RDS instead of Containers for the SQL Databases. In this case it can be a little bit challenging to figure out how to get the databases in RDS. This blog will walk through a sample solution.

Step 1: Take a backup of the databases

Take a backup of the databases, for example from a development environment VM which has the databases installed. Sitecore 10 comes with a Graphical setup package which is great to quickly setup a new Sitecore 10 environment including databases.

Step 2: Upload to S3

At this point you should have a backup of all your databases in a .bak format. Upload all these databases to AW S3. Make sure the S3 bucket is in the same region as your RDS database instance.

Step 3: Restore Databases through RDS’ SP

Databases need to be restored through RDS’ Stored Procedures. This page has a detailed overview but restoring a database can be done through the rds_restore_database SP. It is recommended to not change the database name during restore as it can cause some issues, see troubleshooting section for more details. See example below:

exec msdb.dbo.rds_restore_database 
	@restore_db_name='database_name', 
	@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name.extension',
	@with_norecovery=0|1,
	[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],
	[@type='DIFFERENTIAL|FULL'];

Troubleshooting

A few common issues can occur during this process:

  • Contained database issues: in RDS you cannot enable contained database authentication through sp_configure stored procedure. Instead it needs to be set on the parameter group, see my other blog post for more details.
  • Issues with xDB containers not getting healthy: if the databases were renamed during the restore there is a good chance some of the xDB roles will not get healthy. The Xdb.Collection.ShardMapManager database has some tables which contain rows with connection info including names of other databases which contain the shards. If the databases have been renamed while they have been restored then this connection info will be incorrect. This can be fixed manually or through the SQL Sharding Deployment Tool.
Advertisement

Power Sitecore with CloudFront

On By Jeroen de GrootIn AWSLeave a comment

There are already a few good blog posts which describe how to use CloudFront in combination with Sitecore. All the posts I saw used CloudFront as a solution to offload images and other static resources on a different domain, and then change Sitecore to load static resources from this different domain. Sitecore itself will not be using CloudFront. This post will describe a different approach where Sitecore sits behind CloudFront as well. It will also discuss the advantages of using this approach.

Before diving into using CloudFront for Sitecore lets quickly look at the approach of just offloading static resources to CloudFront on a separate domain. Following flowchart shows this in more detail:

This is an good solutions and it solves the issue of making the site faster by delivering large resources quicker from edge locations globally, at scale and in a more cost effective manner.

Advantages of using CloudFront with Sitecore

In the previous setup Sitecore pages are not using CloudFront, and therefore cannot take advantage of some useful CloudFront features like:

  • Security at the Edge: CloudFront provides protection against most common DDoS attacks. It can also be used to block traffic from certain countries or only allow traffic from a specific set of countries
  • SSL Offloading/compression: SSL can be terminated at CloudFront and CloudFront could gzip compress the responses. Even when not offloading SSL, SSL will be more efficient with CloudFront as it will reuse connections between itself and the origin
  • Restricting access to premium content: if you have premium content which users need to pay for then you can use signed URLs or signed cookies to limit access. This is much easier to standup then a fully fledged IDP but still provides enterprise grade security.
  • Error Pages: Sitecore can handle most common errors better than CloudFront can. However some catastrophic errors are better handled outside of Sitecore, for example a scenario where the app pool is crashing or hanging or a scenario where Sitecore is unable to handle the incoming load. CloudFront supports customized error pages depending on what gets returned from the origin. More info can be found here.

Host Sitecore behind CloudFront overview

This article will will describe a different solution where everything is fronted by CloudFront, and there is only one URL. This way all CloudFront features can be leveraged for both the Sitecore pages as well as all other resources. The origin in this case will be the Sitecore ELB. Below diagram explains this in more detail:

Now that Sitecore pages are also fronted by CloudFront they could be setup to be cacheable, see number 3. Recommendation is to never do this when using Sitecore as all analytics and personalization will not apply and register the page view when CloudFront returns it form cache.

Setting up Sitecore behind CloudFront

This section walks through some of the important configuration when setting up Sitecore’s ELB as the origin of the load balancer.

Set Sitecore ELB as origin

When creating the CloudFront distribution the ELB which hosts Sitecore needs to be set as the origin, see below screenshot:

Allowed HTTP Methods

Since all traffic goes through CloudFront it is important to allow all HTTP verbs which your site uses, e.g. POST, PUT, DELETE etc. See below screenshot for this option in the UI.

Configure caching

There are 2 ways to control how long content stays in the CloudFront cache, more details can be found here

  • Using headers to control cache duration for individual objects: CloudFront will honor the Cache-Control and Expires response headers to control how long objects stay in the cache. This is recommended by CloudFront and personally I also prefer this approach as everything can be controlled from the Sitecore site in IIS.
  • Specifying the amount of time that CloudFront caches objects: In this case the values for time to live are specified in CloudFront. To use this select “Use legacy cache settings” and then “Customize” under object caching, see screenshot below

Understanding other CloudFront settings

There are many other settings in CloudFront and using them correctly can be critical for your site to work properly and to gain maximum benefit from CloudFront. This page provides more detail about all the different settings and how they work.