Earlier today I blogged about Geo-Replicated Application Deployment in Azure for those looking for true high-availability deployment. In that article, I noted that it isn't possible to deploy something like DNN to those environments without a bit more consideration. This posting looks at the special considerations, and some potential suggestions to work around DNN in these types of environment.
DNN Architecture
The DNN Infrastructure, for the most part, is quite flexible and can scale well, however, there are a few inherent limitations to DNN architecture that plague users in all types of horizontal (more servers) scaling situations. It is important to understand these limitations, and more importantly to understand workarounds to get the best bang for the buck in implementation.
Most DNN installations will initially scale-up (adding memory and/or CPU) rather than horizontally. In these situations you will not experience any of the common gotcha issues it is only once you start to scale to more servers that you will experience other issues. Let's look at DNN's specific items that need attention, keeping in mind the information from the other article still applies 100%.
File Synchronization
The issue hardest to solve in a scale-out model within the App Service environment for DNN is file synchronization. When using an App Service in Azure it is expected that the filesystem for the application will either stay static or that the changes are not changes that need to be synchronized across the various nodes included in any deployment.
It is common in DNN for files to change in the application daily, or more frequently that need to be synchronized, resulting in a major problem for basic Geo-Redundant deployments.
Commonly Changed Files
When we look at a DNN installation we can start to identify the scope of changes to see what exactly we might be up against. The first things that people think about are the changes to the /Portals/ folder and all of the sub-folders within. This is, in fact, the most common, however, for many installations, it might not be all of the items to be concerned with. When looking at an installation each third-party module that allows for content upload could be introducing files in a manner that is problematic.
For example, there are a number of third-party content management modules (blog, news, image, etc) that will store their content inside of the /DesktopModules/{ModuleName} folder. This is done for their own protection, they don't want users accidentally deleting the files. However, this effectively blocks your ability to use a distributed environment if you don't have a file synchronization process in place, which might require more dedicated hardware such as VM's and a shared filesystem to keep the data in sync. PaaS offerings will be limited.
Uncommon Processes
It is also important to remember the less-common situations. Module installs/upgrades, DNN Platform upgrades, and other site maintenance activities will change files in multiple directories. These will need to be distributed to all servers in the environment.
Partial Workaround for File Sync
Aside from going to a true Virtual Machine based environment and solving for file replication in the traditional manner with shared drives or network storage, it is possible to mitigate the risk with proper planning and good use of third-party modules.
If your installation ONLY changes files in the /Portals/ directory you can use a third-party, or Evoq, folder provider to move that folder storage into the cloud independently. This can go to Azure, Amazon, or otherwise, the key being that uploading/changing files no longer impacts the actual local DNN file system, negating the need for regular synchronization. DNN log files and other items will still be written to the individual servers, which is fine.
You would then only need to handle synchronization for upgrades and module installs which is far easier to manage.
DNN Cache Providers
Out of the box, with the current version, DNN 9.2.2 does not have a distributed caching provider. This means that application cache is kept locally to a server, either in memory or files. A web-based provider is coming to the DNN Platform release in the future and various third-party solutions also exist but would need to be integrated. Evoq installations do have an option available currently.
There are multiple types of providers available some that use Web Requests to expire cache, such as the provider available from NBrane. You also have providers that utilize a centralized cache repository such as the Redis Caching Provider available from David R. In a Geo-Redundant environment it is far more efficient to utilize provider similar to that of the Redis one to limit the number of back-and-forth transmissions for your application.
The Impact
This will add another piece to your infrastructure with a monthly cost starting at $40/month, but often is a source of great performance improvement as well. In an Active/Passive situation, it is possible to skip this implementation as you would not use the secondary location at the same time as the primary.
There are some modules that do not play well with "out of process" cache systems as well which could limit the ability for this to work, so adequate testing is imperative to success here.
Summary
Once file replication & cache management have been solved it is easy to make a DNN installation Geo-Redundant within Azure or any other environment. New installations desiring this configuration are easier to manage, but it is possible to address these types of concerns with an existing installation it just takes a little bit of effort to accomplish the goals.
As always I hope this helps, share any comments below.