Has anyone had any luck with this? We are NOT using elastic beanstalk. We ARE using load-balancing EC2 instances with auto-scaling. There is NO file sharing, all front-end web servers have their own storage.
1 master EC2, 2 slave EC2s.
So, looking at the documentation, it's all about Azure and it's terrible implementation creating caveats., Seems to me I don't need to tell Umbraco where to store it's indexes in this scenario.
Thing is I can't see any other setting that makes slaves know they are slaves and should update their caches accordingly.
Did I miss a point?
FWIW we are using S3 for media storage. No one is editing front-end files (scripts, templates, css) etc, so I think that rules any need for file syncing?
It does "just" work, ignore all those Azure articles.
Main thing is media in S3 which you have done.
Next stop users logging into the backoffice on your content servers.
Templates need to be shared among the servers - we are using a code first approach so our templates get deployed with the app.
You don't need to use the master slave setup for managing the cache, you can allow each box to run its own scheduler and manage its own, I even wrote my own health check which checks the cache is up to date with the DB, and if not the box gets binned and replaced.
The way it fires up new instances elastically makes it very difficult to keep things in sync and Azure's well documented poor performance.
From the docs...
If you plan on using auto-scaling
Important! Your Examine path settings need to be updated! Azure Web Apps uses a shared file system which means that if you increase your front-end environment scale setting to more than one worker your Lucene index files will be shared by more than one process. This will not work! In ExamineIndex.config, you need to tokenize the path for each of your indexes to include the machine name, this will ensure that your indexes are stored in different locations for each machine. An example of a tokenized path is: ~/App_Data/TEMP/ExamineIndexes/{machinename}/Internal/. This however has some drawbacks for two reasons:
Azure web apps migrates your site between workers without warning which means the {machinename} will change and your index will be rebuilt when this occurs
When you scale out (increase the number of workers), the new worker will also rebuild it's own index
We are working towards being able to mitigate these issues by adding the ability to store a master index in blob storage so that when new workers come online they can sync the existing index locally (this is not yet in place)
Nothing is saved on the file system. Media is saved on a separate cdn and the rest is in the umbraco DB.
when a new (blank) box is deployed, your umbraco deployment is ran so a fresh install of umbraco is deployed. job done.
AWS Flexible load-balancing
Has anyone had any luck with this? We are NOT using elastic beanstalk. We ARE using load-balancing EC2 instances with auto-scaling. There is NO file sharing, all front-end web servers have their own storage.
1 master EC2, 2 slave EC2s.
So, looking at the documentation, it's all about Azure and it's terrible implementation creating caveats., Seems to me I don't need to tell Umbraco where to store it's indexes in this scenario.
Thing is I can't see any other setting that makes slaves know they are slaves and should update their caches accordingly.
Did I miss a point?
FWIW we are using S3 for media storage. No one is editing front-end files (scripts, templates, css) etc, so I think that rules any need for file syncing?
Well, it just works (editing content on master cms, seeing change in front-end server) I guess I should be happy (I am).
No config necessary, (just some url rewriting on front-end servers to prevent backoffice access).
Does that sound right?
It does "just" work, ignore all those Azure articles. Main thing is media in S3 which you have done. Next stop users logging into the backoffice on your content servers. Templates need to be shared among the servers - we are using a code first approach so our templates get deployed with the app. You don't need to use the master slave setup for managing the cache, you can allow each box to run its own scheduler and manage its own, I even wrote my own health check which checks the cache is up to date with the DB, and if not the box gets binned and replaced.
Actually there was something, I added it, took it out, still worked (obviously the original add kicks something off)
to all indexers and searcher configs.
Seems that's the only necessary change.
Would be nice to have that confirmed.
that change is only necessary on Azure, on AWS delete the setting, you don't need it
Hi Alastair,
I am also using the same environment. Can you tell me how to share the code, template and views from the admin to behind the loadbalancer servers.
I just created an AMI - standard windows web server. deploy as you normally would to each. make that setting on the slaves. that's it.
you might want to add some urlredirects on the slaves for /umbraco save any unintentional updates from them.
this worked for me because I use S3 for images so no need to content sync the filesystem.
Hi Alistair,
Could you expand upon that please? What's the difference? What makes it so terrible?
The way it fires up new instances elastically makes it very difficult to keep things in sync and Azure's well documented poor performance.
From the docs...
If you plan on using auto-scaling
Important! Your Examine path settings need to be updated! Azure Web Apps uses a shared file system which means that if you increase your front-end environment scale setting to more than one worker your Lucene index files will be shared by more than one process. This will not work! In ExamineIndex.config, you need to tokenize the path for each of your indexes to include the machine name, this will ensure that your indexes are stored in different locations for each machine. An example of a tokenized path is: ~/App_Data/TEMP/ExamineIndexes/{machinename}/Internal/. This however has some drawbacks for two reasons:
Azure web apps migrates your site between workers without warning which means the {machinename} will change and your index will be rebuilt when this occurs When you scale out (increase the number of workers), the new worker will also rebuild it's own index We are working towards being able to mitigate these issues by adding the ability to store a master index in blob storage so that when new workers come online they can sync the existing index locally (this is not yet in place)
That's really interesting!
So how does scaling work on AWS then if it doesn't use a shared filesystem with workers? How does it avoid concurrency issues in the backoffice.
Btw I think that adding the machine name token instruction might be out of date. I'm sure I've read you shouldn't now.
Update,
Yeah Examine 1.83+ Doesn't require this
https://github.com/umbraco/UmbracoDocs/blob/f4360b4830b744f97c0d503aeeb1596cbf84d4f4/Getting-Started/Setup/Server-Setup/Load-Balancing/flexible.md
Nothing is saved on the file system. Media is saved on a separate cdn and the rest is in the umbraco DB. when a new (blank) box is deployed, your umbraco deployment is ran so a fresh install of umbraco is deployed. job done.
Media can be saved outwith the filesystem on Azure also. What about Applugins, Umbraco folder etc?
Those folders should be part of your site deployment which is replicated on each slave web server
They are using AWS so it doesn't have the same issues as Azure, auto scaling works fine in AWS if you have Umbraco configured correctly.
Hi Alastair / Phil,
Can anyone help me out for setting up the Autoscaling with ELB?. Since I am new to Umbraco. what are the things need to be in place?
is working on a reply...