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'm no expert in cloud computing - I've spent a fair bit of time researching it and various providers but am yet to get any hands-on experience with it. From what I've read about AWS and auto-scaling EC2 instances though, it seems as though each instance should be completely decoupled from all other instances. i.e. If content is uploaded to the web server's local filesystem from a custom CMS backend then that content won't be available if subsequently requested from a different web server in the auto-scaling group. Is that right?

I met with a representative of our existing hosting provider recently and he was claiming that it isn't a problem that our legacy CMS system is highly dependent on having a local filesystem. He said that all web servers, regardless of how many, would be kept as exact duplicates so I shouldn't notice any difference compared to our existing setup of a single dedicated server. This smells a little too much like bull fecal-matter to me...should I be skeptical about this? I'm a little worried because my (non-technical) boss who ultimately makes the decisions is all for signing up to this cloud solution because it won't require any extra work.

I'm sure that they must at least be able to provide this, otherwise they wouldn't be attempting to sell it to us. But at what cost? It sounds as though each web server will always need to be checking the other web server(s) for new static content, which to me sounds like unwanted overhead that'll slow things down.

I'd really appreciate it if somebody could clear this up to me. I'm all for switching to AWS and using S3+CloudFront for all static content, but that isn't looking very likely to happen at the moment.

share|improve this question
2  
Why didn't you... or why don't you... ask them to explain how they accomplish that? –  joeqwerty Dec 11 '12 at 17:10
    
As I mentioned, I'm new to cloud computing. The way the guy was pitching this was making me doubt what I thought I knew about how to handle static content, and that having this content automatically be available to any web server in the cloud was in fact the norm. I guess I just wanted to clarify here whether or not I understood this correctly, and also to get a non-biased opinion of whether this sounds like a good thing or not? I doubt they'll be too eager to criticise themselves! ;) –  RobMasters Dec 11 '12 at 17:21
    
Can they provide you a technical demo of what they are describing? i.e. take a test drive for a week. A test drive in which you are allowed to install your web platform and see it actually work. That should help alleviate your concerns. (some, at least) –  JDS Dec 11 '12 at 18:57

3 Answers 3

up vote 0 down vote accepted

To serve an application that relies on a consistent backend filesystem, the synchronization would have to be omnidirectional and would need to block any write requests until all copies are updated... very hairy business to get working correctly to say the least, and any internal bug of such a system will have cataclysmic consequences.

Probably they actually operate all your web heads off a single massive backend storage (NFS or filesystem-aware SAN), which can introduce a single point of failure.

share|improve this answer
    
You're right, it turns out that there is just a single storage system that is shared between all web servers. This is fine for now I suppose, especially considering the fact our legacy code is still very filesystem dependent, but I'd be worried about the number of disk operations when things start to pick up. Anyway, I'll cross that bridge when it comes! Thanks. –  RobMasters Dec 14 '12 at 9:27

If you're talking about static files, there are clustered, replicated solutions like Gluster which would accomplish this, relatively seamlessly and with pretty reasonable overhead.

You likely wouldn't want to run something like a MySQL database on it, though.

share|improve this answer

I don't mean to sound "cheeky" or nonchalant, but, it depends upon the service and the price. It is possible to do filesystem replication and it is possible to do block replication on SAN devices. You would have to ask your provider if they are utilizing either of these two technologies...and you need to know the distance between the replication sites. The distance between replicated sites will change how well the systems are replicated. Replication via SAN is going to cost you something. Replication via service or filesystem may be free (if they are replicated via rsync or something).

share|improve this answer
    
That's good to know, thanks. It's sounding as though my initial understanding was correct then; that filesystem replication is possible but isn't the standard when it comes to cloud web servers. I'm not really looking for an answer on how filesystem replication is possible though - I'm trying to find out if this is fundamentally a good idea or whether it would be better (cost/efficiency) to remove the filesystem dependency and move static content to S3+CloudFront (CDN) instead? One concern I'd have is that if a web server runs out of space, ALL web servers would need scaling up. –  RobMasters Dec 11 '12 at 18:03
1  
There isn't a "standard when it comes to cloud web servers" - the term covers a very wide variety of different setups. –  ceejayoz Dec 11 '12 at 18:49

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.