I'm considering using Azure for an upcoming project, and I have a couple of questions for those that use it. We'd probably be running each web server as a VM (as there is a bunch of non-Umbraco custom stuff that needs to run as well), and I'm wondering how you'd handle a couple of issues:
1) Media. What's the best way to store the media on Azure VMs? Can you have a shared drive between all the VMs, or do you need to have a replication script that copies updates from a primary VM to the others?
2) With the above, if using replication, how does it work if you scale up and add another web server? How do you get the replication to work?
3) Umbraco has a configuration setting for distributing cache updates on load balanced websites. Does this work for Azure? If not, what do you have to do to get it to work?
Any advice from folks that have used Azure would be greatly appreciated. A lot of the info regarding Umbraco and Azure that I can find refers to the old WebRoles, rather than VMs!
VM's are great, easy to setup and you can actually "see" the server desktop you want ot work on. Plus they are still the only recommended way to scale Umbraco. Trouble is there is no way to simply "add more servers" each one needs to be setup/deployed which is a pain.
1) Media. You can attach a network drive to a machine but there is no "shared drive" that we could find. Best bet is stick it up on a CDN (ie Azure Blob Storage) the new IFile stuff in Umbraco can handle this pretty nicely and its what it was built for. This solution once setup scales pretty well as the settings don't need to change. Bit rubbish if developing local though sometimes so something to be aware of and ImageGen etc need some thought as to how you might be doing that, not sure about the new baked in ImageCropper, assuming thats using IFile in which case it should just work.
2) The sync script thing can work but need modifying everytime you want to add another VM so we tend to avoid that one.
3) With a VM you get an internal to Azure address to hit the server direct so you just reference that, can't remember what it is off the top of my head though. This should never change for you VM (unlike websites where there is no way to safely identify a website instance). It works but always needs some tweaking to make sure it actually is working.
You still need to setup a site that acts as the admin interface too, you should not let editors edit on the VM's direct as it causes all sorts of issues that you jsut don't spot when developing, its a "out in the wild" issue thats a horror to put right after the fact so ALWAYS have a dedicated site for admin/editing of the backend.
Yep, pretty much. You can take a snap shot (forgotten what Azure call it, image?) and spin one of those up but they all tend to need a little fettling.
We've taken to bakingin some logic to try to let the code work out what it should be doing/using as much as possible by having a shared config file etc with all the server settings in and then just that instance sniffs out which one to use based on IP address or similar. Not ideal but cuts done on config hell.
Azure, media sync and scaling
Hi,
I'm considering using Azure for an upcoming project, and I have a couple of questions for those that use it. We'd probably be running each web server as a VM (as there is a bunch of non-Umbraco custom stuff that needs to run as well), and I'm wondering how you'd handle a couple of issues:
1) Media. What's the best way to store the media on Azure VMs? Can you have a shared drive between all the VMs, or do you need to have a replication script that copies updates from a primary VM to the others?
2) With the above, if using replication, how does it work if you scale up and add another web server? How do you get the replication to work?
3) Umbraco has a configuration setting for distributing cache updates on load balanced websites. Does this work for Azure? If not, what do you have to do to get it to work?
Any advice from folks that have used Azure would be greatly appreciated. A lot of the info regarding Umbraco and Azure that I can find refers to the old WebRoles, rather than VMs!
Tim.
Hi Tim,
VM's are great, easy to setup and you can actually "see" the server desktop you want ot work on. Plus they are still the only recommended way to scale Umbraco. Trouble is there is no way to simply "add more servers" each one needs to be setup/deployed which is a pain.
1) Media. You can attach a network drive to a machine but there is no "shared drive" that we could find. Best bet is stick it up on a CDN (ie Azure Blob Storage) the new IFile stuff in Umbraco can handle this pretty nicely and its what it was built for. This solution once setup scales pretty well as the settings don't need to change. Bit rubbish if developing local though sometimes so something to be aware of and ImageGen etc need some thought as to how you might be doing that, not sure about the new baked in ImageCropper, assuming thats using IFile in which case it should just work.
2) The sync script thing can work but need modifying everytime you want to add another VM so we tend to avoid that one.
3) With a VM you get an internal to Azure address to hit the server direct so you just reference that, can't remember what it is off the top of my head though. This should never change for you VM (unlike websites where there is no way to safely identify a website instance). It works but always needs some tweaking to make sure it actually is working.
You still need to setup a site that acts as the admin interface too, you should not let editors edit on the VM's direct as it causes all sorts of issues that you jsut don't spot when developing, its a "out in the wild" issue thats a horror to put right after the fact so ALWAYS have a dedicated site for admin/editing of the backend.
Hope that helps
Pete
Thanks Pete! Very useful info, that's given me plenty to have a think about :)
So for scaling with the VMs, it's still a pretty manual process, as you have to configure the VM etc after it's been created?
Yep, pretty much. You can take a snap shot (forgotten what Azure call it, image?) and spin one of those up but they all tend to need a little fettling.
We've taken to bakingin some logic to try to let the code work out what it should be doing/using as much as possible by having a shared config file etc with all the server settings in and then just that instance sniffs out which one to use based on IP address or similar. Not ideal but cuts done on config hell.
is working on a reply...