Raven running in Azure
97 views
Skip to first unread message
Mark Rendle
Jul 30, 2010, 10:30:36 AM7/30/10
to ravendb
Hi.
After a bit of struggling, I have succeeded in getting RavenDB to run
on a Worker role in Windows Azure.
Worker roles don't allow HttpListener, so I forked the project and
added a TCP-based implementation of Ayende's IHttp* abstractions.
Fortunately, thanks to those abstractions, I didn't have to make
changes anywhere other than the HttpServer.
There is an instance running (as at 30 July 2010) at
http://ravenworker.cloudapp.net:8080/raven/index.html which I'll leave
active until I need the role for something else.
My fork of RavenDB, with the Cloud project in the Samples solution, is
at http://github.com/markrendle/ravendb
Right. Now for some serious testing.
Cheers,
Mark
After a bit of struggling, I have succeeded in getting RavenDB to run
on a Worker role in Windows Azure.
Worker roles don't allow HttpListener, so I forked the project and
added a TCP-based implementation of Ayende's IHttp* abstractions.
Fortunately, thanks to those abstractions, I didn't have to make
changes anywhere other than the HttpServer.
There is an instance running (as at 30 July 2010) at
http://ravenworker.cloudapp.net:8080/raven/index.html which I'll leave
active until I need the role for something else.
My fork of RavenDB, with the Cloud project in the Samples solution, is
at http://github.com/markrendle/ravendb
Right. Now for some serious testing.
Cheers,
Mark
Carlos
Jul 30, 2010, 8:08:37 PM7/30/10
to ravendb
This is great. It would be excellent to have this in the product
itself.
Thanks for the great work, Mark.
On Jul 30, 7:30 am, Mark Rendle <m...@markrendle.net> wrote:
> Hi.
>
> After a bit of struggling, I have succeeded in getting RavenDB to run
> on a Worker role in Windows Azure.
>
> Worker roles don't allow HttpListener, so I forked the project and
> added a TCP-based implementation of Ayende's IHttp* abstractions.
> Fortunately, thanks to those abstractions, I didn't have to make
> changes anywhere other than the HttpServer.
>
> There is an instance running (as at 30 July 2010) athttp://ravenworker.cloudapp.net:8080/raven/index.htmlwhich I'll leave
itself.
Thanks for the great work, Mark.
On Jul 30, 7:30 am, Mark Rendle <m...@markrendle.net> wrote:
> Hi.
>
> After a bit of struggling, I have succeeded in getting RavenDB to run
> on a Worker role in Windows Azure.
>
> Worker roles don't allow HttpListener, so I forked the project and
> added a TCP-based implementation of Ayende's IHttp* abstractions.
> Fortunately, thanks to those abstractions, I didn't have to make
> changes anywhere other than the HttpServer.
>
> active until I need the role for something else.
>
> My fork of RavenDB, with the Cloud project in the Samples solution, is
> athttp://github.com/markrendle/ravendb
>
> My fork of RavenDB, with the Cloud project in the Samples solution, is
Julien Brunet
Jul 31, 2010, 6:00:38 AM7/31/10
to ravendb
Hi,
This is really interesting, but as far as i know from ravendb it still
stores for now its data/indexes to the local filesystem - and because
of this it is unable to run in azure, let me explain:
Despite numerous similarities, azure instance management is not
designed like amazon ec2 : you don't explicitly allocate named
instances in azure, you only can ask for "give me N instances for this
role".
So from there it is almost impossible to have a controlled sharding
strategy. But things are worst:
azure cloud design delivers global availability of your services by
redounding instances and automatically restore them in case of
failure. And by restoring we mean a blank, fresh local file system,
probably on a different virtual machine -> say by bye to anything
stored locally
Hence as long as ravendb cannot write its data/indexes to one the
azure persistent storage subsystems (blobs/tables/queues/sql), it WILL
fail on azure.
disclaimer : i am not stating that either azure or ravendb are badly
designed - only that there is a strong incompatibility between the
two, for now. And the problem is exactly the same with mongodb.
On 30 juil, 16:30, Mark Rendle <m...@markrendle.net> wrote:
> Hi.
>
> After a bit of struggling, I have succeeded in getting RavenDB to run
> on a Worker role in Windows Azure.
>
> Worker roles don't allow HttpListener, so I forked the project and
> added a TCP-based implementation of Ayende's IHttp* abstractions.
> Fortunately, thanks to those abstractions, I didn't have to make
> changes anywhere other than the HttpServer.
>
> There is an instance running (as at 30 July 2010) athttp://ravenworker.cloudapp.net:8080/raven/index.htmlwhich I'll leave
This is really interesting, but as far as i know from ravendb it still
stores for now its data/indexes to the local filesystem - and because
of this it is unable to run in azure, let me explain:
Despite numerous similarities, azure instance management is not
designed like amazon ec2 : you don't explicitly allocate named
instances in azure, you only can ask for "give me N instances for this
role".
So from there it is almost impossible to have a controlled sharding
strategy. But things are worst:
azure cloud design delivers global availability of your services by
redounding instances and automatically restore them in case of
failure. And by restoring we mean a blank, fresh local file system,
probably on a different virtual machine -> say by bye to anything
stored locally
Hence as long as ravendb cannot write its data/indexes to one the
azure persistent storage subsystems (blobs/tables/queues/sql), it WILL
fail on azure.
disclaimer : i am not stating that either azure or ravendb are badly
designed - only that there is a strong incompatibility between the
two, for now. And the problem is exactly the same with mongodb.
On 30 juil, 16:30, Mark Rendle <m...@markrendle.net> wrote:
> Hi.
>
> After a bit of struggling, I have succeeded in getting RavenDB to run
> on a Worker role in Windows Azure.
>
> Worker roles don't allow HttpListener, so I forked the project and
> added a TCP-based implementation of Ayende's IHttp* abstractions.
> Fortunately, thanks to those abstractions, I didn't have to make
> changes anywhere other than the HttpServer.
>
> active until I need the role for something else.
>
> My fork of RavenDB, with the Cloud project in the Samples solution, is
> athttp://github.com/markrendle/ravendb
>
> My fork of RavenDB, with the Cloud project in the Samples solution, is
Ayende Rahien
Jul 31, 2010, 6:18:50 AM7/31/10
to rav...@googlegroups.com
As I understand this, you can allocate a disk to an Azure instance, and then you run Raven on that disk.
Azure will instance instance + disk.
Julien Brunet
Jul 31, 2010, 8:17:40 AM7/31/10
to ravendb
ah, it all make sense with Azure VHDs, yes. Thanks!
On 31 juil, 12:18, Ayende Rahien <aye...@ayende.com> wrote:
> As I understand this, you *can* allocate a disk to an Azure instance, and
On 31 juil, 12:18, Ayende Rahien <aye...@ayende.com> wrote:
> As I understand this, you *can* allocate a disk to an Azure instance, and
Mark Rendle
Jul 31, 2010, 1:01:31 PM7/31/10
to ravendb
Yes, the Sample I have made uses an Azure CloudDrive for the Raven
data files. You can download the VHD from blob storage for backup.
Mark
data files. You can download the VHD from blob storage for backup.
Mark
Ayende Rahien
Aug 1, 2010, 5:00:17 AM8/1/10
to rav...@googlegroups.com
Can you create a blog post describing the steps to set this up?
Reply all
Reply to author
Forward
0 new messages