Running RavenDb on Azure Website

[Jeremy Holt]

I apologise if this has been asked before, but I have gone through a lot of posts that refer to running Raven under a worker role.

My requirements are very simple...

I would like to take advantage of the 8 free sites offered by Azure Websites, and have RavenDb serving all 8 sites (ideally 8 different databases). The traffic is very low. There is no need for replication or sharding etc.

I am very new to Azure and am completely overwhelmed by all the options (only started looking at it yesterday).

I managed to set up a VM and installed IIS and RavenDb and it works perfectly well. I also managed to set up Web deploy to the VM so I can publish directly from VS 2013.

I'm not very happy messing around with the server - I know that every time I install a new version of RavenDb I manage to screw up the IIS instalation.

So my question is: is it possible to install RavenDb on an Azure Website, and if so how?

Many thanks in advance

Regards

Jeremy

[Kijana Woodard]

You can. The question is, where will the data live.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Holt]

I would like the data to be on the same server.

Another (related question). Can I put the RavenDb in the app_data folder in VS 2013 and publish (web deploy) the db at the same time as I publish the site?

[Kijana Woodard]

The "problem" with azure web sites is your not guaranteed to be running *only* one server or on the *same* server between requests. They can bounce you around infrastructure at any moment. 

I don't know if they allow writing to app_data, but if they do, it should be ephemeral data that can be replaced.

The same is true with writing to the "D drive" on an azure VM. It is faster and will be there for a while, until it's not.

[Jeremy Holt]

Well - I don't really mind where the data is, so long as I can access it from my app. I set up an SQL Server for another old app which works fine.

I guess I could create a "Store" at RavenHQ (Azure) and get the app to point to it - but it is quite expensive.

[Chris Marisic]

The points Kijana raises I would say makes WAWS to be a bad choice for a host. It probably will work. Up until one day it doesn't work. At this point you will be frantically rushing to download the database playing wizard with esentutl while praying for good fortune that your data wasn't corrupted.

The disk storage on WAWS is intended for simple file hosting so that users can transition existing websites/applications to WAWS without needing to rebuild them. It is not meant for database hosting.

@Kijana yes you can write to App_Data just fine. It's permanent storage, but in time of a server transition really wonky things likely could happen for an application like Raven.

The other reason to not  hosted in WAWS is you have no scalability / high availability story. You will not be able to scale from 1 instance to 2 as then the instances will both be trying to write to the same stuff and bad things are guaranteed to happen.

[Kijana Woodard]

1. I could be wrong.

2. The data will be there, until azure websites decides to move your app for it's own reasons. Then it's gone.

3. Even if it did work, if azure websites scales you up to two instances, the two instances would be working with two different databases (each in their own app_data).

Expensive as opposed to ...?

[Kijana Woodard]

Ok. You beat me to it.

[Chris Marisic]

On Tuesday, August 19, 2014 4:04:36 PM UTC-4, Kijana Woodard wrote:

2. The data will be there, until azure websites decides to move your app for it's own reasons. Then it's gone.

The data is permanent. It is not ephemeral storage.
 

3. Even if it did work, if azure websites scales you up to two instances, the two instances would be working with two different databases (each in their own app_data).

Yes and no. There will be 2 databases one on server A, one on server B. However there is a low level synchronization process (probably at the block level) that mirrors the data between the server. This works great for simple files such as upload image with write once data. However for a database such as Raven that will be executing writes repeatedly across different portions of the same files, I can only see bad things occurring. Like data destruction bad things.

In a single server scenario I would expect at some point you would lose some transactions that could be fixed by esentutil throwing away corrupted transactions. In a multiple instance scenario, i suspect you would destroy your database.

[Kijana Woodard]

Interesting. I didn't know they would move data that didn't come from the deployment. In other words I thought "balance to new server" == deploy from scm. Even with a sync for images, you could get some temporary 404s. That might not be terrible in such a case.

Can you run esentutil on azure websites?

--

[Jeremy Holt]

OK - guys - thanks for the valuable input. So WAWS is out.

However, am I correct in thinking there is no problem in installing Raven on the VM together with the application? Or, I am I better off using RavenHq? 

I noticed that Raven HQ is available only for US East Coast. I have registered my VM and SQL Server on Brazil South. Is there a penalty in having the data in the US and the app in Brazil?

The app is working perfectly well at the moment on the VM. My real issue is configuring IIS to host multiple sites with one IP address. At the time this was done in the past, our provider did everytihing for us, including registering the CNAMES etc. The registers are on their DNS server which I have no access to.

[Mircea Chirea]

1. Running RavenDB inside a Windows VM is fine. In fact that's the recommended way to host RavenDB.
2. RavenHQ frees you from the need to maintain a VM, and is cheaper for low data volume / low performance needs (as opposed to a A1 VM).
3. With the DB in the US and apps in Brazil there will be several problems:
1. It will be slow. Very slow.
2. You will play for traffic between the DB and apps at standard Azure rates (outgoing from app to RavenHQ).
4. RavenDB should not be hosted inside IIS unless you need what IIS offers; run it as a Windows service, it's much easier to maintain.
5. Hosting multiple sites on a single IP is fine for plain HTTP; for HTTPS, the browser must either support SNI or you need a dedicated IP for each SSL certificate.

[Felipe Leusin]

I just recommend checking your latency to US East and Brazil South. I have no idea why but my latency (from Rio de Janeiro, Brazil) is smaller do US East than to Brazil South (located in São Paulo), I spent hours trying to find out why is that with no luck and basically gave up and kept my infrastructure on US East which is ~20% cheaper than Brazil South and you get to use RavenHQ with very little latency.

[Chris Marisic]

It's really interesting, the story they came up for disk access for WAWS is literally one of a kind. It stands head and shoulders above competitors like AppHarbor & Heroku. To my knowledge there is nothing else on the market even remotely similar for what WAWS provides for migrating an application with simple disk access needs to a highly available environment with no changes.

On Tuesday, August 19, 2014 5:05:15 PM UTC-4, Kijana Woodard wrote:

Interesting. I didn't know they would move data that didn't come from the deployment. In other words I thought "balance to new server" == deploy from scm. Even with a sync for images, you could get some temporary 404s. That might not be terrible in such a case.

Can you run esentutil on azure websites?

Is it possible? Perhaps. It would likely be complicated. Such as trying to execute  Process.Start, or perhaps you could get it to execute as a WebJob with a frequency of 1.

 

[Jeremy Holt]

Felipe,

I'm in Castanhal (interior of Para) using Vivo 3G - what a joke! My best download speed is 0.25 kps! So the question of latency is moot. If you have found that US East is better from Rio than from SP, I'll move everything over right away.

I haven't looked yet, but I assume that I can move my server?

Abs

Jeremy

[Jeremy Holt]

Mircea,

Thanks for the pointers.

I have RavenDb running inside IIS. Doing this I can log on to studio remotely from my local machine. Will I be able to continue doing that if I have Raven running as a service?

Thanks

[Justin A]

IMO

1. Websites on MAWS

2. DB on RavenHQ or Azure VM (based on DB size etc).

[Kijana Woodard]

"Will I be able to continue doing that if I have Raven running as a service?"

Yes. I've done this on an azure VM by simply opening the relevant port [8080].

[Kijana Woodard]

I should say exposing the relevant port. 

You have to expose the port in windows [on the VM] and in the azure portal.

[Felipe Leusin]

Jeremy,

You should test for yourself, I used a tool called tcping for my tests but googling now I found http://azureping.info/ that gives me similar results.

Best of luck,

Felipe

[Jeremy Holt]

Felipe,

Just tested it - there is almost no difference between South Brazil and the US addresses. SB generally comes out a little faster. However, I don't think that VIVO helps very much.

This ping is weird!!

South Brazil (Sao Paulo)	177 ms
South East Asia (Singapore)	439 ms
East Asia (Hong Kong, China)	447 ms
West Japan (Osaka)	488 ms
East Japan (Saitama)	576 ms
East USA (Boydton, Virginia)	2517 ms
North Central USA (Chicago, Illinois)	2578 ms
West USA (California)	2625 ms
North Europe (Dublin, Ireland)	2648 ms
West Europe (Amsterdam, Netherlands)	2692 ms