WordPress is the leading content management system today owning more than 50% of the market share. WordPress on Microsoft Azure is becoming a very popular offering with the ability to host WordPress as an Azure WebApp. While Microsoft has made the process of spinning up a WordPress site very easy with built in gallery images, running business critical applications on a cloud platform also introduces challenges in terms on availability and scalability.

WordPress Architecture

A typical WordPress deployment consists of the following two tiers:

  • Web Frontend – PHP web site
  • Backend Data store
    • Relational data store – Hierarchical entity store
    • Object data store – Used to store uploaded images and other artefacts

In order to guarantee high availability and scalability, we need to ensure that each of these service tiers are decoupled and can be separately managed.

 Web frontend

Windows Azure supports WordPress to be deployed as an Azure WebApp. Azure WebApp is a part of the Azure App Services offering, a fully managed service which can host mission critical web applications.

Azure WebApps natively supports scaling which can be achieved by increasing the number of instances of the hosting WebApp. The native Azure load balancer takes care of distributing the traffic amongst these instances in a ‘round robin’ manner. WebApps also support schedule-driven and automatic scaling.

HAWP1

Azure Portal can be used to configure scaling rules for the WebApp.

Azure WebApps offers an uptime of 99.95% for basic, standard and premium tiers even with a single instance of deployment . Azure Load Balancer takes care of managing failover amongst instances within a region. To achieve higher availability, the application front end can be deployed across different geographical regions and Azure Traffic manager can be employed to handle load balancing, network performance optimization and failover.

HAWP2.PNG

Backend Store

WordPress back consists of two data stores. One, a relational data store which is used to store WordPress entities along with their hierarchies and second, an object store used to persist artefacts.

Azure Gallery hosts a prebaked image for Scalable WordPress, which lets you configure a scalable MySQL backend as the relational store and uses Azure Storage as the object store for your WordPress deployment. Scalable WordPress uses Azure Blob store to host uploaded artefacts.  This works well for most of the scenarios.

HAWP3.PNG

It is important to understand that by using a MySQL backend for your WordPress site you are engaging with a third party database-as-a-service provider (which in this case is Clear DB). This means that the availability SLA associated with your WordPress backend is not provided by Microsoft. Always check the SLAs associated with your chosen pricing tier with the third party provider.

An alternative is to use Project Nami, which offers a WordPress image configured to run against Azure SQL Database as the back end. You can deploy the WordPress site with a Project Nami image either from the Azure gallery or from project’s website. Nami supports WordPress version 4.4.2 with a fully configurable Azure SQL Database backend. Once deployed, the WordPress instance can be configured to use Azure Storage as the object store by employing Windows Azure Storage for WordPress plugin.

HAWP4.PNG

Using SQL Azure and Azure Storage as backend for your WordPress site has the following key advantages

  • Eligibility for Microsoft SLA – A minimum uptime of 99.9% is guaranteed on Azure Storage and an uptime of 99.99% is guaranteed on Basic, Standard, or Premium tiers of Microsoft Azure SQL Database.
  • Easily manageable – Azure SQL databased can be provisioned and managed using Azure Resource Manager templates or through the portal.
  • On-demand scaling – Azure SQL database supports on-demand scaling to meet changing business demands and traffic.
  • More secure – Azure SQL databases offers better support around auditing and compliance apart from offering highly secure connections.

 Conclusion

To conclude, you can deploy a highly available WordPress site in Microsoft Azure by ensuring that the front end and backend tiers are fault tolerant and designed for failure. The deployment strategy can be influenced by the following factors:

  • Choice of technology for the backend – Microsoft (SQL Azure)/Non-Microsoft (MySQL)
  • SLA requirements
  • Logging and Auditing requirements
  • Scaling, security and manageability requirements

References

Project Nami – http://projectnami.org/

Scalable WordPress – https://azure.microsoft.com/en-us/marketplace/partners/wordpress/scalablewordpress/

 

Category:
Architecture, Uncategorized
Tags:
, , , , ,

Join the conversation! 9 Comments

  1. Thanks for the mention about us. But I’d like to point out that Project Nami came out of beta almost a year ago with our 1.0 release.

    Reply
    • Thanks for point that out Patrick.I have fixed this in my blog. I use project Nami for my personal WP site and I am loving the experience. Thanks for giving us a great product.

      Reply
  2. I’m having a bit of trouble making the disaster recovery scenario work for Scalable WordPress.

    We set the storage account to be geo redundant and read accessible, cloned the web app to the partner Azure data center, and put Traffic Manager in front of it but seem unable to make the secondry azure blob store be referenced by the DR web app.

    It would a shame to not be able to use Azure blob storage for the media content, when all the other parts of the DR puzzle are there already.

    Posted here against the Azure storage plugin for WordPress forum – https://wordpress.org/support/topic/azure-ra-grs-support-disaster-recovery?replies=1#post-8172314

    Reply
  3. Hi Chris,

    Not sure why you need to point your WebApp to a secondary Azure blob store explicitly when your Primary is RA-GRS? RA-GRS will replicate your files on 6 copies offering you a good amount of redundancy. Ideally pointing all your front end deployments to the primary blob store with high availability configured on your blob store should address most of the DR scenarios. Is there any specific corner case you are trying to address?

    You should be able to reach the secondary endpoint explicitly through the URL which looks like:

    “Name-secondary”-secondary.blob.core.windows.net

    more on this can be found at https://azure.microsoft.com/en-us/documentation/articles/storage-redundancy/#read-access-geo-redundant-storage

    – Namit

    Reply
    • Hi Namit,
      The case I was aiming to address is if there is a storage problem on the primary, which we have experienced previously in Azure. The storage was online but suffering latency issues. Unfortunately at this stage it’s dependent on Microsoft to make a decision to fail over, and that won’t typically happen unless there is a major disaster.

      So far I’ve found a few issues with trying to get the secondary web app to use the secondary endpoint. One is that it seems to change it on the primary too, and it doesn’t seem to let you select the container properly. Second is that even when it’s changed over, it appears all the links to media still refer to the primary. It looks like these are all hard coded in the database. In a pinch, I can see there are tools to bulk update the database to change over the url’s, but it’s not something that’s automatic.

      Reply
      • Hi Chris,

        I understand the scenario. One solution may be to place your azure storage endpoints behind traffic manager and use performance mode for traffic routing. This should take care of latency issues. I have not tried this myself but theoretically this should work.

        More about performance traffic routing can be found here
        https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-routing-methods/#performance-traffic-routing-method

        Thanks,
        Namit

      • That’s a interesting approach – I just wonder how it would work as a blogger if you are closer to the read only secondary and try to upload content.
        At the moment, it seems the storage plugin for Azure needs some work, as it doesn’t let you specify the full address in the configuration, only the storage account name.
        We are starting a discussion with Microsoft to see if something can be developed, perhaps the use of Azure CDN instead would be useful too.

  4. @Namit have a very useful post with illustration, I wanted to add more to it with step by step guideline, if any body interested I have put together a series of posts related to Scalable WordPress Site Using Azure at

    https://www.scientistz.com/2017/10/how-to-create-scalable-optimized-wordpress-siteblog-using-azure-mysql-azure-storage-and-azure-cdn-part-1/

    I hope it will help. Again Thank you Namit.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: