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!

Okay, I'm admittedly NOT a programmer or IT systems person. I'm a librarian by training, who has, through years of effort, become a web manager and information architect. So, when our programmers suggest some possible frameworks for our Drupal installation's backend, I'm just clueless.

Mosso's Cloud Sites hosting environment, now the Rackspace Cloud (What was wrong with Mosso?), has worked brilliantly so far after an initial scare (see earlier post here). Last week, we reached another perceived impasse where we thought, again, that we needed a Cloud Server in order to accomplish a multi-site Drupal installation. Our programmers just couldn't see how we could get away without shell access to the Cloud Sites environment on the Rackspace Cloud where can do more complex configuration than perhaps Drupal itself, in php, would allow.

Alas, after discussing our concerns with our Systems Administrator and chatting with someone at Rackspace (their "fanatical tech support" is still great!), we are sticking with the Cloud Sites platform. The scalability of Cloud Sites, the low cost factor and the managed environment (no server updates, Apache configuration, keeping MySQL up-to-date, etc.) is very desirable for our needs. Ironically, in reading about Cloud computing and setting up systems similar to what we're doing, the theme was repeated over and over: "your IT or Systems folks will want more control, root access, etc." - however, in our case, it was our Systems person who asked repeatedly: "Why do you need root access" and argued against it for the reasons I cite above (scalability, managed server environment, etc.) and ultimately convinced us that we think that indeed we do NOT need root access, at least at this point.

So, we're diving deeply into our programming and implementation phase of preparing Drupal for ca. 70 sites, each with their own Drupal but managed from a central or master Drupal install - "Multi-site with single codebase" as it's called in Drupalese.

So, we're underway with our single Drupal installation in the Mosso Cloud Sites platform. We will eventually have 70-80 websites running on a single install of Drupal there. Right now, we have to actually learn how to use Drupal! Thankfully, there seems to be no shortage of resources. Just a few:

UPDATE! It works!

We have successfully achieved creating multiple sites with one instance of Drupal via Aliases in the Cloud Sites platform. We just tested and seems to work fine!  

Last week, on the recommendation of several people from Mosso, we set up a Cloud Sites account with the intention of migrating 80 websites into that platform all running on a single Drupal install. I was told on the phone by 2 people at Mosso that this was do-able. After the initial installation and testing, we were unclear as to how this would work with Apache config access so that we could configure the virtual host entry in httpd.conf. So, I tweeted this question out on my Twitterfeed. Someone from Mosso responded saying that in fact, what we were attempting wasn't possible - that we, in fact, needed a Cloud Server. Also, we asked one of our consultants and were pointed to this blog post. Very frustrating...

But, I persisted with Mosso and setup a Cloud Servers account and called a meeting with our current systems people. In the meantime, I canceled the original Cloud Sites account at which time I was contacte by an Account Manager at Mosso who inquired as to why we were canceling. I explained the situation and he responded that I had gotten bad info. That, in fact, we CAN, I repeat, CAN run multiple sites from one instance of Drupal in the Cloud Sites platform. That, while they don't support wildcard DNS, they do have an "alias" system that allows for subdomains or other domains to point to a single instance of Drupal on another site. So, we could have www.oursite.com as the "primary" site where Drupal is isntalled and many subdomain.oursite.com sites that, via the "alias" in Cloud Sites, point to the www.oursite.com install and are thus run by it, Drupal-speaking. This was fantastic news. We really didn't want to have to mess with a server, keep it up-to-date, etc.

So, now we're testing this by attempting to point real domains that we own to our new Cloud Sites IP and see if the aliasing will work. It looks promising as it worked on a local installation we have of Drupal here. But, through all of this, I have to say that Mosso's so-called "fanatical tech support" is the real reason that a) we figured this out and b) are still a customer of Mosso. Thanks, Mosso folks!

Okay, we have our first Acquia Drupal installation in our cloud. Now working through some important configuration/backend information architecture decisions that will likely affect all we do going forward with Drupal. One of the biggest and actually most basic decisions we've made is whether to have one master drupal installation/MySQL database to run all 80-odd sites we manage or to have one master installation of Drupal with 70-odd separate sites (subdomains) each with their own "installation profile" of Drupal and their own MySQL database. The latters seems to be the best choice for us for many reasons:

Okay, so I hope this list speaks the truth about the "cloud" because several of my concerns or conundrums were alleviated after I read this post by James Governor on Red Monk. Namely, these items:

                         ^