I would like some input on how we could configure and optimize Umbraco 7 (or 6 - probably similar) to work on either Azure websites or cloud services, with the ability to scale the number of instances on demand.
So, the objective is:
1. Host the application on Azure 2. Make it possible to scale the number of instances 3. Use the umbraco rendering engine 4. Content editing for editors
This of course will introduce some challenges, so some compromises could be relevant, such as
- Not being able to use the media section - Having to implement custom code to keep content caches in sync across n number of instances - We will not be doing things like adding templates etc. on the cloud instances
With the information I have been able to compile about websites and cloud services, I see there would be different challenges
Websites:
Websites share the file system, so with multiple instances we would get file locking issues on Lucene indexes, and possibly also on Log4net logs and the umbraco.config file. There would probably also be an issue with assigning a single instance to be the "editing" instance, if that is needed
Cloud services:
Cloud services do not share the file system, so the opposite problem presents it self. How do we sync files (if needed) across instances? It is also my understanding that the default file storage on a cloud service instance is not persisted in the same way as websites, which means that non-deployment/non-recreateable files need to be stored on a separate store somehow.
Common:
Since the number of instances is dynamic, the standard load balancing approach will not work, as we cannon configure the instances to ping eachother. This means that some sort of polling mechanism will need to be implemented in order to make the instances autonomous, yet up to date.
So with all that, what are you're (hopefully successful) implementations of Umbraco on a scalable Azure platform?
Have a watch of the Red Bull session from Codegarden. Cant remember if it was Azure but i know they had issues about syncing media across the instances.
In short you can't do it and have it scale all that easy.
VM's are still the recommend way to go if you want a pure Umbraco setup. Its possible to vertically scale these VM's up if needed and you can put them in and out the pool for a cost. All pretty manual stuff though.
Websites currently won't work as far as we know for the reasons you raise although you can ease some of the pain by having a separate editor instance (same DB coonection string though) and push all your media up to blog storage.
We've hit the all same issues and have been working on a solution in house which removes some of the headaches by removing umbraco from the front end completely and going pure MVC fronend with a lot of pixie magic to keep all the content in sync between all the instances. Its not ideal for every build but our logic is if you need to scale then you are in "custom code waters" anyway so might as well embrace it.
Damian, I did watch the Red Bull case, but as you know that is a quite extreme example. It looks like they actually did a combo of the traditional load balanced setup and a CDN caching strategy. But they are not scaling their "origin" servers, as they called them.
Peter, The thing about running VM's is that then you are in charge of the OS level as well, and you lose some of the neat things with automated deployments etc. You do have a good point about maybe just having one "editor server", and the have the other servers live off the main servers data, but do it's own caching. However I'm thinking that you might be able to have them all be umbraco sites, and then just have some code on the "delivery" servers the will mimic whatever umbraco does on app startup on a scheduled basis, and get the sites up to date in that way. So then the question becomes how to schedule such a thing on each instance. But then again, maybe we don't need the full umbraco codebase on the servers, but just the content from it.
To further elaborate on this, here is some of my thinking, let me know what's seems feasible and what not.
We are looking to run a site on Azure Websites across multiple different instances. All these instances share the same drive so this raises some concerns as mentioned above
1. Media:
I suspect this will be fine as multiple instances can write to the same folder no problem. The unique key given to each media item is derived from the database so there should be no risk of conflicting names
2. Multiple editors
As the website is scaled across multiple instances all running under the same domain with dynamic IP addresses, there is no way to create a single instance for administrators. However, editing multiple instances is not a problem (after all, this is kinda the point of the web) it's more refreshing the cache across all the instances once a change has been made. Usually you would use the "Distributed Calling" for this purpose to clear the memory & umbraco.config caches etc., however without fixed IP addresses this is problematic. Is my assumptions on this correct?
3. Lucene
As multiple instances of the site is running you would have problems with multiple sites trying to create/ manage / re-index indices on Lucene which I can only imagine would cause locks and other associated problems.
4. Umbraco rendering
This should not be a problem for us as all templates will be pulled from source control. Again, is it safe to assume this is not a problem?
5. Log4net
This again should not be a problem as we could just change this to log to the database instead.
My question is, has anyone found solutions to some of these problems? It's been a while since this issue has been addressed and I was wondering if anyone has made any progress on this. Regarding the caching issue, I don;t think having a slight delay on this would be problematic. Since the database is the central point of contact would it make sense for each instance to ping the database once a minute (configurable off course) for a "publish version" and if the version has changes, it clears the appropriate cache associated with that instance? This could solve the multiple editors scenario and should not impact the performance of the site?
This leaves the problem of the Lucene indexing. Again, could each instance not register themselves and the fist one running has the honourable duty of building the indexes etc. whilst the others ignore this? The application environment does notify you when an instance is shutting down so it could de-register itself with the service. Again, they could ping every few minutes and if an instance does not respond in the allocated time frame, responsibility moves onto the next active instance?
Apologies for the over simplification, just brainstorming here as we really need a solution to these problems.
In my opinion using Azure Websites is the way to go, because it's the best fit out of the box. Bottomline I call it "Load balancing without the headache", because of the x-drive architecture of WAWS. About a year ago I also gave a presentation about Azure websites for the Dutch Umbraco User Group. The slides are in dutch, but hopefully they are helpfull enough: www.slideshare.net/JeroenWijdeven/jw201312-duug-umbraco-op-azure-websites
In short:
- Azure websites does share the same file system across all "IIS role" instances see slide 11. The file based cache and media items are therefor automatically synced across all instances. - Set ContinouslyUpdateXmlDiskCache to true.
The challenge: - Examine / Lucene is not supported, check this on how to support it: https://github.com/Shandem/Examine/wiki/Examine-with-Azure-Websites ; - Log4net, log to the database is prefered in my opinion because of the possible file locking. - Multiple editors at one time could theoretically lock cache files etc, I never experienced the problem myself because the editor teams I worked with are to small to test this correctly. If you challenged the Lucene and use a database for log4net, multiple editors may not be a problem.
I really like to hear what other developers experienced..
First of all a nice post to join the debat. When I read it, I read some frustration. On th other side I was maybe a bit to enthusiastic ;-). However I think for a lot of basic Umbraco sites WAWS is still the way to go because it easily fits on the WAWS architecture and the way Umbraco works (but keep in mind that there are challenges for certain situations). When I read the post I don't think you guys are working on a basic implementation and more complex situations have different needs.
I don't read anything in the post that you couldn't know before starting the project.
Media folders can be a pain while setting up a classic load balancing senario in Umbraco. With WAWS it works out of the box. It doesn't meet your performance needs, but that's not an Umbraco issue it's an issue for WAWS. Maybe WAWS wasn't the right choice in the first place for your website?
Examine doesn't work well. That's a known issue and it's discussed many times. The plugin Shannon is made is in POC phase. He is very clear about this. I think when you have good idea's or code improvements you have to join or fork his project, we are an opensource community at the end of the day.
I really like to hear about your findings with the umbraco.config, I think it only can be locked when multiple editors (on different instances) are publishing stuff at the same time.
So bottom line:
Can Umbraco run on Azure? Yes. Can it scale without problems? Yes. Can it scale without problems in every situation? No. Is there any CMS in the world that fits all people needs? No. Is there any car in the world that every body likes? No .. Is there a holy grail? we don't know, or read the Da Vince Code..
p.s. Is there any one in the Umbraco core team that could write a post on the challenges you guys came up with during the implementation of Umbraco as a Service. As far as I understand it runs on Azure (Cloud services? WAWS?).. Does UAAS support auto scalling, how are the challenges fixed, and how does it perform?
Haven't you gotten the umbraco.config part backwards?
The config setting you mention will actually make each server have its own cache file in the ASP.net temp folder of the server.
If I recall correctly, there is a setting that will make each server monitor the shared file for changes, which you will need if the auto scaled instances are not set up to ping each other.
Yes, the setting is making the umbraco.config to be moved to each machine temp folder. The setting you are mentioning is XmlContentCheckForDiskChanges set to true. And with the umbracoContentXMLUseLocalTemp to false this would have the effect I've described. I will correct the post. Thanks for the catch!
@Chuhukon I'm the author of the post so maybe I will explain. The post is not an attack on Umbraco or a way to take off my frustration. It's just an explanation of the problems I have while creating the solution to share it with the community. Not everything was clear on the beginning and easy to find. But first of all maybe a brief introduction.
Why Umbraco was choosen? Because we (the company) have the most experience in Umbraco developement. I still think it's the best .NET based CMS with great community.
Why hosted on Azure? Request from the customer and new policy of the company to move everything into the cloud.
Do I have much experience with Azure? Nope.
Was one the requirements scaling? Yes.
Why WAWS? Several reason. But the most important is the ease of use and maintability. Also from the articles and tutorials I've read it's the the recommended way of Umbraco hosting for the future.
Indeed our project was not basic Umbraco use as CMS (custom data types with external DB communication, custom indexes, lot's of custom code injected with controller hijacking, DI container etc.).
I know there would be a challenge and may require some additional work from - I didn't expect a holy grail (yes I read the book once teenager- now I'm think it's crap:D)... I'm also aware of the fact that some of the issues are connected with Azure itself, not Umbraco or with the additional libraries that have bugs.
But just to comment your points:
- Sticky session - it's clear but better for us to store session on Redis than InProc - save precious machine memory, but there was no problem here
- Media folder in blob - we spend much time tracking the issue with the blob provider and there was a chance to lost some data of the customer, but of course we've contributed to the project itself and the version available now on NuGet is stable - btw. thanks to the author https://github.com/idseefeld. Why Blob? Because of the latency issue (Azure problem).
- Examine on blob - indeed this project is a POC, but you couldn't find that info on the project documentation (https://github.com/Shazwazza/Examine/wiki/Examine-with-Azure-Websites), I found this info on Umbraco forum after we ran into problems with that. So could I know that before the project has started? Yes. Was that clear on the project documentation? No. Was Shazwazza helpfull with explaining the problem once I've asked and realized? Hell yes! Is this something I would like to contribute? For sure.
- umbraco.Config - sure I will share once I will have some more data. For now now I could not say nothing more since the site handles the traffic perfectly fine with only 1 machine. But indeed that could be the only way to have lock - update on the same time on different instances.
PS I also think it would be very interresting to read a post from Umbraco core team member about the UAAS implementation and the challenges they struggled.
Azure instance scaling with Umbraco 7
I would like some input on how we could configure and optimize Umbraco 7 (or 6 - probably similar) to work on either Azure websites or cloud services, with the ability to scale the number of instances on demand.
So, the objective is:
1. Host the application on Azure
2. Make it possible to scale the number of instances
3. Use the umbraco rendering engine
4. Content editing for editors
This of course will introduce some challenges, so some compromises could be relevant, such as
- Not being able to use the media section
- Having to implement custom code to keep content caches in sync across n number of instances
- We will not be doing things like adding templates etc. on the cloud instances
With the information I have been able to compile about websites and cloud services, I see there would be different challenges
Websites:
Websites share the file system, so with multiple instances we would get file locking issues on Lucene indexes, and possibly also on Log4net logs and the umbraco.config file. There would probably also be an issue with assigning a single instance to be the "editing" instance, if that is needed
Cloud services:
Cloud services do not share the file system, so the opposite problem presents it self. How do we sync files (if needed) across instances? It is also my understanding that the default file storage on a cloud service instance is not persisted in the same way as websites, which means that non-deployment/non-recreateable files need to be stored on a separate store somehow.
Common:
Since the number of instances is dynamic, the standard load balancing approach will not work, as we cannon configure the instances to ping eachother. This means that some sort of polling mechanism will need to be implemented in order to make the instances autonomous, yet up to date.
So with all that, what are you're (hopefully successful) implementations of Umbraco on a scalable Azure platform?
Have a watch of the Red Bull session from Codegarden. Cant remember if it was Azure but i know they had issues about syncing media across the instances.
Might be quite useful.
http://stream.umbraco.org/video/8315762/handling-22-million-visits-redbull
I know this is not exactly answering your question but thought you might find it useful and interesting given your quesion. :)
In short you can't do it and have it scale all that easy.
VM's are still the recommend way to go if you want a pure Umbraco setup. Its possible to vertically scale these VM's up if needed and you can put them in and out the pool for a cost. All pretty manual stuff though.
Websites currently won't work as far as we know for the reasons you raise although you can ease some of the pain by having a separate editor instance (same DB coonection string though) and push all your media up to blog storage.
We've hit the all same issues and have been working on a solution in house which removes some of the headaches by removing umbraco from the front end completely and going pure MVC fronend with a lot of pixie magic to keep all the content in sync between all the instances. Its not ideal for every build but our logic is if you need to scale then you are in "custom code waters" anyway so might as well embrace it.
Might have something to release about that soon.
Damian, I did watch the Red Bull case, but as you know that is a quite extreme example. It looks like they actually did a combo of the traditional load balanced setup and a CDN caching strategy. But they are not scaling their "origin" servers, as they called them.
Peter, The thing about running VM's is that then you are in charge of the OS level as well, and you lose some of the neat things with automated deployments etc. You do have a good point about maybe just having one "editor server", and the have the other servers live off the main servers data, but do it's own caching. However I'm thinking that you might be able to have them all be umbraco sites, and then just have some code on the "delivery" servers the will mimic whatever umbraco does on app startup on a scheduled basis, and get the sites up to date in that way. So then the question becomes how to schedule such a thing on each instance. But then again, maybe we don't need the full umbraco codebase on the servers, but just the content from it.
Hi guys,
Do you have any news on this? We are really keen todo something similar for a high volume site?
Regards
Gordon
To further elaborate on this, here is some of my thinking, let me know what's seems feasible and what not.
We are looking to run a site on Azure Websites across multiple different instances. All these instances share the same drive so this raises some concerns as mentioned above
1. Media: I suspect this will be fine as multiple instances can write to the same folder no problem. The unique key given to each media item is derived from the database so there should be no risk of conflicting names
2. Multiple editors As the website is scaled across multiple instances all running under the same domain with dynamic IP addresses, there is no way to create a single instance for administrators. However, editing multiple instances is not a problem (after all, this is kinda the point of the web) it's more refreshing the cache across all the instances once a change has been made. Usually you would use the "Distributed Calling" for this purpose to clear the memory & umbraco.config caches etc., however without fixed IP addresses this is problematic. Is my assumptions on this correct?
3. Lucene As multiple instances of the site is running you would have problems with multiple sites trying to create/ manage / re-index indices on Lucene which I can only imagine would cause locks and other associated problems.
4. Umbraco rendering This should not be a problem for us as all templates will be pulled from source control. Again, is it safe to assume this is not a problem?
5. Log4net This again should not be a problem as we could just change this to log to the database instead.
My question is, has anyone found solutions to some of these problems? It's been a while since this issue has been addressed and I was wondering if anyone has made any progress on this. Regarding the caching issue, I don;t think having a slight delay on this would be problematic. Since the database is the central point of contact would it make sense for each instance to ping the database once a minute (configurable off course) for a "publish version" and if the version has changes, it clears the appropriate cache associated with that instance? This could solve the multiple editors scenario and should not impact the performance of the site?
This leaves the problem of the Lucene indexing. Again, could each instance not register themselves and the fist one running has the honourable duty of building the indexes etc. whilst the others ignore this? The application environment does notify you when an instance is shutting down so it could de-register itself with the service. Again, they could ping every few minutes and if an instance does not respond in the allocated time frame, responsibility moves onto the next active instance?
Apologies for the over simplification, just brainstorming here as we really need a solution to these problems.
Thanks in advance for any input on this
Regards
Gordon
Nothing new here?
G
That bit of kit I talked about has a name: http://getjetstream.io/
Hoping to show off a bit of it at UK Festival you can make it?
In my opinion using Azure Websites is the way to go, because it's the best fit out of the box. Bottomline I call it "Load balancing without the headache", because of the x-drive architecture of WAWS. About a year ago I also gave a presentation about Azure websites for the Dutch Umbraco User Group. The slides are in dutch, but hopefully they are helpfull enough: www.slideshare.net/JeroenWijdeven/jw201312-duug-umbraco-op-azure-websites
In short:
- Azure websites does share the same file system across all "IIS role" instances see slide 11. The file based cache and media items are therefor automatically synced across all instances.
- Set ContinouslyUpdateXmlDiskCache to true.
The challenge:
- Examine / Lucene is not supported, check this on how to support it: https://github.com/Shandem/Examine/wiki/Examine-with-Azure-Websites ;
- Log4net, log to the database is prefered in my opinion because of the possible file locking.
- Multiple editors at one time could theoretically lock cache files etc, I never experienced the problem myself because the editor teams I worked with are to small to test this correctly. If you challenged the Lucene and use a database for log4net, multiple editors may not be a problem.
I really like to hear what other developers experienced..
Regards, Jeroen.
Our findings: http://blog.orbitone.com/post/Does-Umbraco-really-loves-Windows-Azure
Hi Rik,
First of all a nice post to join the debat. When I read it, I read some frustration. On th other side I was maybe a bit to enthusiastic ;-). However I think for a lot of basic Umbraco sites WAWS is still the way to go because it easily fits on the WAWS architecture and the way Umbraco works (but keep in mind that there are challenges for certain situations). When I read the post I don't think you guys are working on a basic implementation and more complex situations have different needs.
I don't read anything in the post that you couldn't know before starting the project.
Rik, a quick question.
Haven't you gotten the umbraco.config part backwards?
The config setting you mention will actually make each server have its own cache file in the ASP.net temp folder of the server.
If I recall correctly, there is a setting that will make each server monitor the shared file for changes, which you will need if the auto scaled instances are not set up to ping each other.
Yes, the setting is making the umbraco.config to be moved to each machine temp folder. The setting you are mentioning is XmlContentCheckForDiskChanges set to true. And with the umbracoContentXMLUseLocalTemp to false this would have the effect I've described. I will correct the post. Thanks for the catch!
@Chuhukon I'm the author of the post so maybe I will explain. The post is not an attack on Umbraco or a way to take off my frustration. It's just an explanation of the problems I have while creating the solution to share it with the community. Not everything was clear on the beginning and easy to find. But first of all maybe a brief introduction.
Indeed our project was not basic Umbraco use as CMS (custom data types with external DB communication, custom indexes, lot's of custom code injected with controller hijacking, DI container etc.).
I know there would be a challenge and may require some additional work from - I didn't expect a holy grail (yes I read the book once teenager- now I'm think it's crap:D)... I'm also aware of the fact that some of the issues are connected with Azure itself, not Umbraco or with the additional libraries that have bugs.
But just to comment your points:
- Sticky session - it's clear but better for us to store session on Redis than InProc - save precious machine memory, but there was no problem here
- Media folder in blob - we spend much time tracking the issue with the blob provider and there was a chance to lost some data of the customer, but of course we've contributed to the project itself and the version available now on NuGet is stable - btw. thanks to the author https://github.com/idseefeld. Why Blob? Because of the latency issue (Azure problem).
- Examine on blob - indeed this project is a POC, but you couldn't find that info on the project documentation (https://github.com/Shazwazza/Examine/wiki/Examine-with-Azure-Websites), I found this info on Umbraco forum after we ran into problems with that. So could I know that before the project has started? Yes. Was that clear on the project documentation? No. Was Shazwazza helpfull with explaining the problem once I've asked and realized? Hell yes! Is this something I would like to contribute? For sure.
- umbraco.Config - sure I will share once I will have some more data. For now now I could not say nothing more since the site handles the traffic perfectly fine with only 1 machine. But indeed that could be the only way to have lock - update on the same time on different instances.
PS I also think it would be very interresting to read a post from Umbraco core team member about the UAAS implementation and the challenges they struggled.
Hey Mariuz,
Any updates in regards to Lucene and Web apps? We are looking to try and use web apps as our requirements are identical to yours.
Tarek
Take a look at this session from CodeGarden.
The are some news on auto scaling abilities from version 7.3
http://stream.umbraco.org/video/11665943/umbraco-load-balancing
Great,
Thanks for the quick response.
Sorry for the newbie question.
In the scenario of using Azure Web Services for a deployment are you guys using SQL CE for the content database?
Many thanks Si
in case of Orbit One we always use Azure SQL.
I doubt SQL CE is a good idea.
Hi Rik,
Thanks for the response and noted.
Cheers Si
on hindsight, it's possible that SQLCE could work, check with Shazwazza to be sure ;)
is working on a reply...