Drupal in Rackspace Cloud's "Cloud Sites" platform - some tips from our experiences

 

We are in the middle of a content migration of 70 websites to Drupal per this page. We have been using the Rackspace Cloud's Cloud Sites hosting environment as opposed to procuring our own server. At first, we thought this couldn't be done. Then, after some testing and back-and-forth with Rackspace and some research, we discovered it could be done via aliasing in Cloud Sites. See my post here.

However, in the last few months, we've been plagued by intermittent "No suitable nodes are aviable to serve your request" messages on our sites in our multi-site Drupal install in Cloud sites. The Rackspace folks' "fanatical tech support" has been helpful, but, honestly, we have considered leaving a few times. What's kept us there is the tech support and the quality of the service - when it works!

During these last few months, when we had issues, I complained loudly on Twitter and subsequently met several other users in the Rackspace Cloud using Drupal who had similar issues. Thus, I learned a lot about the Rackspace and Drupal. Basically, in Drupal, everything is stored in a MySQL database. So, loading a Drupal site might, no matter how simple, still requires potentially hundreds of DB queries. If one fails or is hung up in the Cloud Sites' MySQL clusters, the page takes forever to load or returns a "No suitable nodes..." message.

Last week, we had more issues with our sites loading extremely slow (more than 30 seconds!) or the "No suitable nodes..." messages being returned. So, we jumped on Live chat in the Rackspace Cloud control panel and were connected with someone named Vincent W., who was very knowledgeable and helpful. He made an excellent suggestion - why not host our MySQL Databases on a separate, dedicated Cloud Server in the Rackspace Cloud? While this would mean a bit more money, it promised stability that couldn't be matched by remaining in the Cloud Sites' clustered environment - MySQL clusters where many DB queries are being fired simultaneously from many users.

So, yesterday, we deployed a Cloud Server (it only takes a few minutes in the Rackspace Cloud) and installed MySQL and migrated a few of our databases. What's genius about this solution is that our files and code (in Drupal, the php and the files) are still in Cloud Sites and don't need to be tweaked at all. We simply needed to point the MySQL database URL in the settings.php for the few sites we moved and voila!, they were now being served by the version of the database on the Cloud Server. And, I'm happy to report that the sites are loading quite consistently fast. (Note: it's hard to tell if they are loading better than Cloud Sites because the days and weeks after a major outage in Cloud Sites, everything loads fast - cache is cleared, etc.). But, they seem to work great and thus, so does this solution.

So, we'll monitoring these sites over the next few weeks and will likely migrate all of databases in this manner. This way, we can take advantage of the hosted environment that Cloud Sites offers, with the stability of having our own server for the databases Drupal needs to serve the pages. Not exaclty an elegant solution but not too bad either!

Share/Save
 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
14 Jan11:42

Thanks

By Ronald (not verified)

Thanks for the write-up. Have been thinking about using this service - guess I will wait and see. Currently on slicehost (which I think is the basis for Cloud Servers) and that is working out fine.  

15 Jan05:55

Keep us posted

By Ivan Zugec (not verified)

Keep us posted on how it's going. I used media temple's grid hosting and had similar issues with performance. I ended up moving over to a VPS.

03 Feb08:26

how do you handle emails?

By zdean (not verified)

how are you able to handle email accounts for the 70 different domains since they are all aliases? When I set up an alias on my cloud sites control panel, I don't see a way to then go in and set up email accounts for those aliases.Thanks.

03 Feb10:47

Answer: we don't have to handle emails

By mavergames

Luckily for us! I have no idea how one would do this. Sorry...Good luck!Chris

03 Feb17:33

Sorry to bug you about this

By zdean (not verified)

Sorry to bug you about this point, but I'm curious how you/your clients get around the email issue. When you say you don't handle emails, do you mean that 1. none of the domains/clients use email connected to the domain so it's a non-issue or 2. the clients handle email themselves...if this is the case, do you know how they do it?This is the last missing link for me to set up a multisite where I would manage sites for multiple clients. But without email support, I don't see how that would be feasible.Thanks for your help!

03 Feb17:42

Answer is 1

By mavergames

Hi again,It's 1. We only offer a shared Drupal themed template and manage the backend modules, config., etc. There are no email addresses involved. They use whatever client/service they use at their local institution, etc.Sorry, I couldn't be of more assistance.Good luck!Chris