Cloud hosting Sitecore - High Availability

-
The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before. 

Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud hosting providers, both support Windows machine images and you can choose to host Sitecore on either.

Another option is Platform as a Service (PaaS) cloud hosting.  PaaS environments further abstract underlying infrastructure, and instead of managing servers and server software PaaS platforms provide building blocks for hosting application services.  This abstraction removes the need to support the underlying operating system, significantly reducing the effort required for deployment, management and even scaling of systems.   Microsoft Azure is positioned as a leader in PaaS cloud hosting, and with its services based on Windows and .NET also supports Sitecore.  Additionally Sitecore provides an Azure module which specifically targets the Azure PaaS platform.

This is the first of a series of blog posts some of the common patterns for enterprise web hosting of Sitecore in the two leading cloud platforms, Microsoft Azure and Amazon Web Services, along with some key considerations for development on cloud platforms in general

 Other posts in this series
Cloud hosting Sitecore - Scaling for peak loads
Cloud hosting Sitecore - Serving global audiences
Cloud hosting Sitecore - Disaster recovery

Pattern 1 - High availability hosting

Web sites are expected to always be online, even for sites that do not have a high traffic load.   Building a high-availability architecture for hosting a website yourself usually requires multiple servers for content delivery and databases along with load balancing.  Whilst this is reasonably standard infrastructure in a medium-large sized organisation, the configuration of servers, database software, load balancing devices and firewall rules take time and careful planning to get right.  

Microsoft Azure

When hosting a Sitecore site on Microsoft Azure, the Sitecore Azure module can completely automate installation and deployment to a load balanced farm of two or more content delivery nodes.   Microsoft Azure warrants a minimum 99.95% uptime service level  for a cloud service with at least two nodes, meaning that you can deploy a high availability farm straight from your Sitecore desktop within minutes by simply clicking on a data centre location, choosing to add a delivery farm and selecting two or more instances.




Another benefit of hosting with Azure and using the Sitecore Azure module is that is supports deployment of staging and production slots for each farm within an Azure data centre location.   You can use the Sitecore Azure module to upload your file changes initially to the staging slot, where they can be tested using a temporary URL.  Once you are ready to publish the update live to your users, you can simply use the "Swap" operation in the Sitecore Azure module. 

The swap operation typically takes less than 60 seconds to switch the staging and production roles, making what you uploaded to staging public.  Similarly the slots can be swapped back again to effect an almost instant rollback if there is a problem.

 Performing an Azure cloud service deployment can take 30 minutes or longer, during which time not all of the nodes are online.  If you need to perform a deployment when experiencing full load on the system this might not be ideal.  In addition, it is useful to be able to test your application in the cloud environment once it has been deployed but before making it available to you users.

Amazon Web Services

Hosting Sitecore sites on Amazon Web Services involves building a hosting environment using Amazon EC2 virtual machines.  This is done by provisioning Windows server images from the AWS console using the appropriate template, and then configuring them and installing Sitecore as you would in a traditional hosting environment.

You can choose to build EC2 instances including SQL Server; however AWS also supports SQL Server through its RDS service which provides some extra capabilities such as mirroring across multiple AWS availability zones with less direct configuration.

Deployment of the Sitecore solution also has to configured manually using a similar approach to what is used with any other hosting environment, however AWS does provide a couple of features that you can use to add additional automation with a little additional work up front. 
  • Elastic Beanstalk is a deployment management technology which can be used to deploy .NET updates to authoring and delivery servers. 
  • CloudFormation allows the scripting and automated provisioning of complete sets of virtual machines and other Amazon services.

 If you are only moving the delivery farm to the cloud, you will also need to manually update your Sitecore configuration to create additional publishing targets for the cloud based delivery farm, and also configure replication of the Core database.

Next...

In the next installment I'll take a look at how you can implement auto-scaling of your Sitecore instances using these public cloud hosting instances.

Comments

Post a Comment

Popular posts from this blog

Setting up TDS to work with Azure DevOps

-
Image
We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 displayName:
Read more

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec
Read more