Sitefinity 4.1 on Azure, is the config persistent?

As everyone is certainly aware, the release of Sitefinity 4.1 is now stated as being Azure ready which is great news!

There are instructions at the URL below for how to set up Sitefinity on Azure:

http://www.sitefinity.com/documentation/installation-and-administration-guide/running-a-project/creating-and-running-projects-on-windows-azure.aspx

This looks straightforward enough, you are basically setting up the DB, a Web Role (Make sure they are in the same Availability Zone) NOTE The docs state that you can only use one Web Role, I assume as there is as yet no sync ability between multiple roles.

The instructions then talk you through connecting RDP to the instance and changing the permissions on the App_data so that it is writeable.
This presumably means that the config for Sitefinity is still being written to this folder as it would be in a standard deployment?

This solution raises a question: what happens when the role gets restarted? As far as I can see the config is only in the files on local storage on the role, so won't the config be lost? If this is not backed up/replicated then the App Fabric will start a new role but the config will be the same as the original deployment package?

I haven't tried this yet, am I missing something?

The other problem with a single role solution (which Microsoft do not recommend) is that during this role restart your site will obviously not be available.

Sitefinity 4 is ready for Load Balancing but this is using the standard IIS NLB stack. It would be good to have some clarity on how this approach is going to converge with Azure support.

I've been saying for a while, I think the best way to achieve all this is to provide a DB option for all config, as this makes the product instantly Azure compatible as well as being useful in a more traditional hosting environment. Why not have 2 Azure SQL DBs, one for config and one for the normal content? That will preserve performance while allowing you to use multiple Roles to achieve scalability and high availability.

Matt

Hello mattc,

You are right, that the configuration is still written under the App_Data folder on the file system of the web role instance VM. The same is also true for the search indexes. You are also right that this is not compliant with Microsoft's recommendations and while a restart of the service will usually use the same VM and won't be an issue, it may cause configuration loss if the Windows Azure Platform moves the instance to another VM (due to hardware failure, or just to offload the current host).

Actually it is Sitefinity's dependency on the file system (for configuration and search indexes) that made us set the single-instance requirement for the current release. We were mostly focusing on the SQL Azure support, as part of the upgraded OpenAccess integration and we haven't done substantial changes to other parts of the system that would make it truly multiple-instance cloud-ready.

We plan to improve on that in the future releases. For instance the synchronization layer that is now used on top of the IIS NLB stack is abstract enough to be customized to support true Windows Azure load balancing in the future and we are planning to implement storage providers that will use Windows Azure blob storage for media content. You are also right that at some point the configuration will have to be stored in some non-file system storage to be shared among multiple web role instances.

Unfortunately at this point we cannot give you an estimate when these tasks will be completed and Sitefinity will be ready to run multiple instances and take full advantage of the Windows Azure Platform features.

Hi Radoslav

Thanks for your answer. I have to say I'm a little disappointed though. Version 4.0 was already Azure SQL ready in terms of DB at launch as I showed nearly 9 months ago in this forum post. There were some connection issues that I pointed out in the same post, but I was told this was an ORM problem and would be fixed. I haven't tested whether this has been fixed in 4.1, maybe someone else has?

As far as I'm concerned this hasn't gone forward at all though. The main difference is that now Azure allows you to RDP to a Role and so can change the permissions on the App_Data folder, allowing it to function on a single role. However nobody in their right mind would use this for anything production, even for a test it will get pretty dull if you can lose your Apps config at any moment you have no control over. There is no point using it.

Yes a provider to use Azure Blob Storage would be great, a DB storage provider is much more urgent I would say though.

There is maybe a work around as long as you are happy with a single Role solution. If you use an Azure Drive and then change the location of the config folder in Sitefinity this might work. The Blob store behind the Azure Drive is persistent so would survive the Role being restarted. I haven't tried this, if Telerik want to give me access to an account I'm willing to get a test working as I did before.

I'm not sure what to do now, I may have to look for other more Azure ready software. I don't think others like Kentico are that far ahead though, last time I looked their version was restricted to single Web Roles and used Azure Drives as well.

I'm disappointed, this was a real chance for Sitefinity to take the lead and it has been missed, a real shame. Maybe it will come, I know there have been lots of other more fundamental problems with version 4 that needed sorting first, but for those of use waiting and hoping for features like this it's getting very frustrating.

Matt

Hi mattc,

We just want to let you know that we are working towards the full support of the Azure cloud. We are currently abstracting how the communication should be done between the servers in the azure NLB and we believe that we will have the full support of Windows and SQL Azure for the second service pack of Siteinity 4.1.

Kind regards,
Radoslav Georgiev
the Telerik team

I successfully got a 4.1 install on Azure.  I did have a problem with my second install, but I was able to fix it by copying my bin directory from the first one (some weird System.* dll version error caused by installing from Windows 7 64 bit and Visual Studio 2010 SP1).  I also plan to check out the shared drive option for an alternate App_Config location in the meantime.  I like how fast SF is on Azure!

I feel it is a good step, and I plan to host most of my sites on Azure going forward.  I agree with Matt that putting config in the database would be best.

Hi Radoslav

Thanks for your reply, that is good news. I feel that SF is very close to becoming truly Azure compatible and that will be a major selling point for it. It has to include the ability to scale with multiple instances and have an independent out of instance config store though.

I think you will be ahead of your competitors if you make these changes quickly.

I still think a DB config provider would be the way to go though, maybe in a separate DB so you would not get any performance hit, caching would also be good etc.

I look forward to seeing it.

Matt

Brian

Sounds good. Yes the shared drive option will be a solution for a single instance deployment, as it will allow your config to persist even if the instance is recycled. As far as I'm aware you can only have one instance with read/write access though, all others will have read only.

It sounds like the team are hoping to make some changes in the next SP, so that is promising.

Matt

Is there any update on this ? Can someone let me know how to setup the shared drive option ? Our role just got restarted and I lost all my config :(

Hi Mark,

Unfortunately we haven't explored the Azure Drive path, as it is restricted to a single instance, and we took the path of storing the configuration in the database (as Matt has also recommended above). We feel this is the most generic approach and it can be utilized in other scenarios too.

We are also working on instance synchronization using internal endpoints and we plan to release our first try on true multi-instance support and database persisted configuration with 4.1 SP2.

For now the only workaround to the lost configuration issue would be to include the configuration and license files in the web application project (check that the Build Action is set to Content in the project item properties), thus making them part of the deployment package. Doing this guarantees that if the web role instance is redeployed by the App Fabric at least the initial state of the configuration will be restored.

This would work, only if your project does not require configuration changes, once it is deployed. Otherwise if the instance is redeployed, any configuration changes after the deployment will be lost, but things like your initial security and data configuration will be kept.

Thanks for the reply -

How do I deal with the following :

1. Giving the App Pool write access to the App Data folder ?
2. Making the config files in the package "writable" - I think by default they will be read-only ? 

Are these things that I will need to do as soon as our site decides to move to another server ?

(I think what I am reading here is that SF is not really "Azure - ready" as it currently says on your front page ?

Ta
Mark

Hello Mark,

Based on Matthew Cooper's feedback and some other clients we have taken the necessary actions to bring our Azure story a step closer to an enterprise class cloud application.

With Sitefintiy 4.1 SP2 release that will be available early next week we will be storing Sitefinity's configuration files in the database. Therefore you won't be required to set any permissions on the AppData folder as it will be read only, so that you don't lose any of your configuration files.

The product will also support up to a few multiple azure instances, so that you can deploy your package and specify more than 1 instance that will load balance your website load. Note that the number of instances should be well align with your website load since more instances with a few clients might spoil the performance

Thank you for contacting us and please let me know if you need further assistance with Sitefinity's Azure support.

All the best,
Hristo Borisov
the Telerik team

Hi Hristo et al.

This is great news, I think you have made a good decision here and will make Sitefinity not only Azure compatible but also able to be used with multiple servers in any environment. I know Azure has been a secondary goal compared to getting the product out there but it's good to see that it is now becoming a development priority.

I look forward to seeing the new release.

Regards

Matt

Nice, Telerik! :)

You have likely saved me some work fine tuning the Azure drive option.  I was fine with a single instance for now, but obviously, as our site load increases, the full cloud multi-instance support is a requirement.

Thanks!

Good news about Azure, and bad news for Standard and below...

SP2 will work on Azure, however, it will not support 2 web roles (as Microsoft strongly recommend). To do this - you need pay $2,000 for the NLB feature (for Standard and below) ...http://www.sitefinity.com/documentation/installation-and-administration-guide/deploying-sitefinity/deploying-sitefinity-projects-to-windows-azure.aspx

However, if you already have Professional ($8,000) or Entreprise ($20,000), then the NLB feature is included.

Here's the licensing page :
http://www.sitefinity.com/purchase/license-comparison.aspx

Seems to me that at least 2 instances should be supported in Standard, Telerik -- where the second instance is really more of a backup of the first, as opposed to a true load balance situation.  Yes, if the load is more than enough for once instance, it should 'load balance', but be limited to 2 instances.  If I want to host my Standard edition on Azure for a moderate load site, I should be able to do that.

I do understand the higher cost for a Sitefinity license that supports true load balancing for more than 2 instances.

Telerik, can you please make this so?

Thanks!

Hi Brian,

Sitefinity Standard Edition doesn't come with support for a load-balanced environment as you indicated. When you purchase the support for NLB add-on for it you don't get to run Sitefinity on just one more server, but unlimited number of servers in a load-balanced environment.

Note that most CMS vendors charge per additional server in a load-balanced environment and Telerik offers unlimited number of servers for a set price.

Best wishes,
Anton
the Telerik team

I think the problem here is that in a "normal" hosting environment, ie stand alone servers used as web servers, by the time you got to requiring a second server in a load balanced configuration you were dealing with a major site and so upgrading to a bigger license was a natural progression and cost effective.

However the advent of Cloud PaaS offerings like Azure has required people to think in a different way. Azure instances are ephemeral, and they are not the same either in terms of power or persistence as your traditional dedicated server. They are designed to be started and stopped often and do so when the Azure system deems necessary. So having one server you make sure has redundant everything in order to ensure it never goes down is not the way it works in Azure, you need several lesser instances. Look at Google App Engine, it goes even further, you don't even bother about the number of instances, you let them scale dynamically. They are all small but you rely on having lots of them when you need them.

Because of this, and it's included in Microsoft's best practices, you should always run a minimum of 2 worker roles to ensure both continuity and good performance. This is the whole essence of Azure, there is no point running just one, you might as well go and get a shared hosting plan somewhere, it will probably serve you better and be cheaper!

I'm afraid that there needs to be a different approach for the licensing on Azure hosting, at the very minimum you need to be allowed to run 2 roles. It's a shame that this doesn't come as standard. Without this there are going to be very few Azure deployments of small sites in Sitefinity.

My suggestion would be make Sitefinity allow 2 instances ONLY if it detects it is running on Azure. If it's running in a standard environment then you need the NLB add on or a bigger license. 

M

Matt

I totally agree with your points - well said. Make sure you get your DB and Web Role in the same region, otherwise SF runs like a dog. (I did it by mistake). Even when you do get both instances in the same region, its still very slow for the backend, which is disappointing.

Cheers
Mark

I'm hugely in favor of making the Standard Edition a 'load-balance lite' version limited to 2 instances.  This would be a very good thing, imho.  It provides a gateway to cloud computing for sites that require a bit more than one server, but not the huge installs for super large sites.

I know you can add load-balance to the Standard Edition, but it is too extensive, as the Standard Edition is already pricey.  Now, if you had to charge something, I'd say $100-200 to add 2 instance load balancing would make sense...

Migrated Sitefinity with the new Azure Portal over the weekend, figured I document it in detail, this may help you  http://blog.longle.net/2012/08/09/migrating-teleriks-sitefinity-cms-to-windows-azure/

Migrated Sitefinity with the new Azure Portal over the weekend, figured I document it in detail, this may help you, here you go  http://blog.longle.net/2012/08/09/migrating-teleriks-sitefinity-cms-to-windows-azure/

Very nice.  I was able to install it on Azure as well.  I still wish Telerik would change the license for Standard Edition to include 2 load balances -- that way you can install the 'backup' instance on Azure and it works well.

Hi Long,

Thank you. This is indeed a nice tutorial!

As you mention that the documentation is not comprehensive enough, could you please point some of the missing/unclear points, so that we can include/clarify them.

Regarding a complete rewrite of the current documentation to reflect the new Management Portal - we canceled our plans to do it. The reason is that our Thunder team already started working on automating some of the steps of the deployment which hopefully soon will provide a much more pleasant experience when deploying Sitefinity to Windows Azure and make "the old way" and the corresponding tutorial obsolete.

Until then, I'm sure your tutorial will be a valuable resource.

Best wishes,
R. Atanasov
the Telerik team