Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a web application and windows service that access the same set of files. I use a named semaphore to stop it from accessing the information at the same time (service or web server requests to have access to the directory, uses it quickly, releases the semaphore).

I want to run this application on Windows Azure. I think using a Virtual Machine would be nice because then I can use a named semaphore to control access, then run both the web server and windows service on the VM. The issue is that the Virtual Machine seems to be kind of limited in space. I need to use way more storage than what is offered for Virtual Machines. I'd also be missing out on the geographically redundant storage.

Is it possible, in Windows Azure, to have a named semaphore shared between a Cloud Service and Web Site? Maybe I need a separate service that has exclusive access to these files and communicates with the both the service and website? That would suck to have to program another service and spend the extra money per month on it. Is there a better way?

Edit (more info):

  • Scaling is definitely needed. There's going to be a lot of data stored and I'm concerned it will outscale the VM in the future.
  • They are not database files. They are individual files with a separate directory that has many different indexes. I'm concerned about the windows service and web server trying to access the same index at the same time (though a rare occurrence).
  • I believe a storage blob would work well in this case.
  • A lease blob would not be good. 15 seconds is too long to wait.

What I think I'll do:

I'll probably have a VM running both the windows service mentioned above and an extra service that does nothing but "manages locks" on the specific indexes and files that are located in a blob. So... the web server or windows service will request a "lock" from this service. That way both application can work directly with the files and it will take less development time to get that going.

Edit 2:

Or maybe I could just put everything on a VM, use a named semaphore, then access the storage blobs (probably the best option for now)

share|improve this question
    
This does not scale - simplest solution is to use a DBMS –  symcbean Aug 15 '13 at 11:19
    
Based on your edits, I think you might not be fully understanding storage blobs. To work with a blob, you'd need to download it to the VM (or provide a URI to an end-user for them to download it). You can't just access it like a normal disk file, unless you keep the blob sitting on disk (and that doesn't scale to multiple vm's if the content changes). As I said: Storing database files in a blob is not going to work, and you should consider an index to be the equivalent of a database file in your case. –  David Makogon Aug 17 '13 at 3:37
    
Yes, I had the impression that that's the way a storage blob worked. To me it seems as though the "Table Storage Service" might be more of what I'm looking for if I can access what I save to this service anywhere. I'm not sure about what I should do about the indexes though. –  dhsto Aug 17 '13 at 19:08
    
I've been doing a lot of reading and since I am using lucene for the different indexes, I will use the Azure Library for Lucene.Net so all the indexes will be stored in a blob, while the individual files (which are in a different format) are stored in a "Table Storage Service" –  dhsto Aug 19 '13 at 1:23

1 Answer 1

up vote 2 down vote accepted

This question is a bit open-ended, as there are many ways to potentially solve this issue. Thinking about Azure specifically:

  • Having an extra service does not necessarily equate to spending extra money. You can run your service on your existing Virtual Machine(s). You could set up your service tier to run in a serial fashion, ensuring no two requests would attempt accessing files at the same time.
  • Regarding limited space: Where are you storing your files? If you place them in the OS disk, this won't scale beyond the OS disk's size (about 127GB). If you attach a disk, you'll have up to 1TB, and you can have 2 attached disks per core, up to 16 attached disks (16GB attached storage) total.
  • If you store files in a file system (either on OS disk or attached disk), you'll have trouble scaling beyond one Virtual Machine, unless you have a separate Virtual Machine running your service and managing storage. Still, you won't be able to scale beyond one "service" Virtual Machine. For Windows Azure, you should really consider storing files in Azure Storage Blobs. Once you do this, you have the ability to access your storage from any number of Virtual Machines (which means you can scale your service tier).
  • Follow-up on previous bullet: I have no idea what type of files you're accessing. If these are database files, then my idea of using blobs wouldn't be practical.
  • For exclusive access across multiple machines, you'd need your own mutex scheme; there's no semaphore construct in Azure that spans machines / services. While blobs have leases, I don't think that's efficient for a high-transaction scenario. However: Imagine you queue up specific requests, then have queue readers handle specific requests. Would this eliminate your object contention?
  • One last thought: Unless you're using Linux, you don't necessarily have to use Virtual Machines. You can also look at Cloud Services (web/worker roles), as these are Windows Server virtual machines that are stateless and have much more flexibility with scaling.
share|improve this answer
    
Thanks a lot! You're very knowledgeable on the topic and I think you've answered most of my question. I've never used Windows Azure and we're considering it as an option. I've updated my question with more info and what I think I will do. –  dhsto Aug 15 '13 at 3:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.