Server Architecture Options for EPiServer

A question that has been posed to me a few times recently is, “What Server Architecture do I need?” That and the painful, “How long will my project take to develop?” but I’m not going to try and answer that one in a blog post!

With server architecture, there are a lot of different options available for EPiServer. The answer generally depends on how editors are expected to access the editing interfaces; whether it is through the live internet servers, an internal server or a content staging environment. Also, load balancing is available for high traffic websites as well as for redundancy.

Below are three common server architectures that are used as well as some considerations to take into account when setting up a load balanced environment. The options are not exhaustive, but are generally the most common.

Option 1 – Editing on the live environment through the internet

This is perhaps the most common architecture, mainly due to ease of setup, ease of access, and licensing costs. The editing interfaces exist on the internet facing live servers and editors access the editing interfaces through a Url such as www.example.com/secure/edit.

This setup is less secure than options 2 and 3 as an infiltrator can access the editing interfaces if they find a username/password through other means. By default the editing interfaces are locked very tightly so a username/password is required, however this information can sometimes be gained through methods such as email sniffing if editors are sending their details to each other.

Pros:

• Ease of setup
• Ease of access for editors
• Lowest licensing costs

Cons:

• Editing interfaces are available over the internet allowing infiltrators access if they have a username/password

Option 2 – Editing on the live environment through a business network

The editing interfaces are removed from the internet facing live servers; however an editing server is placed behind a firewall but still attached to the same database server/cluster and file sharing option. Editors must be within the network to access the edit server which is often achieved through VPN, and then they must also have a username/password to access the editing interfaces.

This option gives extra security over option 1, without the extra setup requirements for option 3. It is most often used when a client is hosting the sites themselves, as the infrastructure is usually already in place to allow for editors to access a server within the network that is also able to access the live database server/cluster.

Pros:

• Requires secure access to business network as well username/password
• Ease of setup

Cons:

• Editors are required to be either on the business network or to have connected via VPN to access the editing interfaces

Option 3 – Editing on a content staging environment

The editing interfaces are removed from the internet facing live servers and a completely separate environment is setup for content staging. Editors access the content staging environment either through the business network, or some other secure access.

This option gives extra security over option 1; however it does require extra setup. Whenever content is published on the content staging environment, it must then be approved to be mirrored to the live environment using the EPiServer content mirroring functionality. This uses Web Services to communicate between the environments.

As there are multiple environments this option has the highest licensing costs but does allow for an extra approval process where a high level editor can see the entire “live” staging site on the content staging environment before sending it, or a portion of it, to the live environment. Whereas with options 1 and 2, only individual pages can be previewed within the context of the published site before they go live.

This option should not be thought of as being more secure than option 2, it is used for a different way to publish content.

Pros:

• Requires secure access to business network as well username/password
• Extra approval process

Cons:  

• Editors are required to be either on the business network or to have connected via VPN to access the editing interfaces
• Extra setup required
• Highest licensing costs

Load balancing considerations

EPiServer is technically able to load balance across as many servers as you need allowing for redundancy and high performance.

There are two main considerations with Load balancing. First is the page content such as the text that an editor enters into a page, and second is the file management such as an image that an editor enters into a page.

Page Content

Whenever a page is updated on a server within a load balanced environment that server will update the local page cache as well as the database. It will then send out a remote event using Windows Communication Foundation to the other servers that are listening alerting them to update their cache as a page has been updated. This event is usually sent by UDP broadcast, but can be configured to use TCP if required.

It must be ensured that all servers within the load balanced environment are able to communicate with each other over the used protocol. Barriers to this are often firewalls (software and hardware based) as well as switches and other hardware that are not configured to forward on certain traffic such as UDP broadcasts.

File Management

EPiServer utilises the Virtual Path Provider from Microsoft which allows for a file to be stored in multiple ways. The default provider used saves the metadata associated with the file in the database; however the file itself continues to exist on the file system, although with a different name and sitting outside of the website root.

This means that the files existing on the file system must be accessible by the different load balanced servers. This is most commonly done through a network share, a SAN or by using some synchronisation software to ensure that when a file gets updated locally on one server, that it is also updated on the other servers. The network share is the easiest to setup, however if redundancy is a reason for the load balanced environment, then this can be a single point of failure for files used on the site.

Further Reading

For more in depth help with certain functions please see the following tech notes.

Content Mirroring: Mirroring - Configuration and Operation

Load Balanced Environments: Configuring EPiServer CMS 5 R2 SP2 Enterprise and Event Management System Specification

I hope this helps with any environments you are thinking of setting up!