A perfect starting point to run RavenDB on Windows Azure as a worker role is this project hosted on GitHub.

Why?

There is no particular reason to run RavenDB on Azure:

  • we are really confident with RavenDB;
  • we have already experienced the power of a document database;
  • we are not so confident with MongoDB and especially:
    • we currently do not really like that in order to run MongoDB on Azure we are required to set it up in a non-already supported Azure Virtual machine;
    • 10gen is also working on a MongoDB Worker Role that is now in beta, so in the near future MongoDB will be a really interesting alternative.
  • we need to be able to set geography constraints, due to privacy requirements, on where our data are stored;

Requirements

Our requirements are really simple:

  1. we need to be able to run on Esent, and not on Munin that is not really supported for production environments;
  2. in order to provide some sort of SLA to our customer we need to be able to setup replica using other worker roles;

Changes

If you download the above sample from github and press F5 in Visual Studio it simply works but after a deeper look it does not satisfies the above requirements:

  • on my machine the startup of the second role to setup the replication silently fails;
  • the sample runs on Munin and simply switching to Esent in the RavenDB configuration breaks everything;

in order to fix and have everything setup and running we followed this steps:

  • In order to run on Esent when dealing with Azure Blob storage and VHD(s):
    • The “Data” directory must be “manually” created otherwise Esent complains with a “Disk IO Error”;
    • The “Tenants” directory must be “manually” created, in order to avoid the same issue as above;
  • The downloaded sample:
    • has a misconfigured endpoint in the role configuration: the endpoint must be http and not tcp;
    • utilizes the “RoleEnvironment.CurrentRoleInstance.Id” to setup the VHD name but, at least in the development emulator, the id changes at each deployment and is prefixed with the deployment id, thus each time the VHD is new and you lose access to the previous debug session data; we managed to create a VHD name using “RoleEnvironment.CurrentRoleInstance.Id” value but removing the “RoleEnvironment.DeploymentId” portion;
    • In my environment running with more than 1 instance breaks everything because of the way the emulator assigns dynamic ports to the second instance, resulting in the choice of an already used port, I suppose it does something like “current port” + 1, thus 8080 + 1 = 8081;
    • I have also removed all the references to the embedded RavenDB version that in our scenario is useless;

Now everything runs and satisfies our requirements and we can point the browser to the local emulator address and see the RavenDB Studio up and running:

image

.m