By Lloyd on

We're hosting on a Media Temple DV Server with root access using Plesk. I can add additional IP addresses if necessary.

We're going to be hosting multiple sites each using Drupal. Some of the sites with be completely standalone, meaning no shared content and completely different domain names (abc.com, xyz.com). Other sites will share some content and have some unique content. They might be a standalone domain name or a subdomain (my.abc.com or xyz.com). We also have the issue of SSL certs as multiple domains will need SSL and I understand (at least somewhat) the problem of multisite hosting when more than one domain needs an SSL cert.

Will this scenario work for a multisite installation or should I just go with standalone and deal with upgrades? Or perhaps it's a combination where the sites that will be having shared content are on a multisite installation and the unique sites on their own. Then, the issue would still be if I can do the multisite installation with SSL given those limitations.

⋅ Categories: Drupal 6.x

Comments

jorgbert’s picture

jorgbert commented

We are rolling out quite a number of Drupal websites across our enterprise. I played with multisite quite a bit, and came to the conclusion that the potential for bringing down related sites sharing the same code, but different databases was unacceptable.

If I have a website respond in an unexpected way during an upgrade there is a lot of piece of mind to know that I am only dealing with one site. Heaven forbid that I bring down 10 to 20 sites at once. I have the emotional bandwidth to stay cool if one site is down, but the rest are blissfully unaware. The same for those whom I pass my creative work on to.

For the same reason I have found it best to keep each Drupal installation in its own dedicated database. A restore involves a single site.

Assuming that each Drupal site has has its own dedicated database (which is very good idea), you are going to run an update on each database anyway -- whether manually or via Drush scripting. And that update has to occur after you copy in the new update, and potentially disable the module while you update it. And as soon as you update it, which often updated the database table structure as well -- guess what? If you are sharing the same updated module code between a site with an updated database, and a multitude of other sites, still on pre-updated databases -- well you get the idea. The last thing I want is a multitude of websites all failing at the same time!

And suppose that I have a particular site with a special module that won't "take" the upgrade, but I don't know until I try it?

And of course, we all "test" our upgrades in a staging area before we make live upgrades, don't we?

The bottom line is that we have a separate VM specifically for staging that is accessible from our Intranet. Each website is capable of standing on its own. We can take a "snapshot" (backup) of a single website just before we upgrade it, and if it blows up on us, it is easy to "roll back". What little extra disk space it takes to keep each website separate is insignificant. What is significant is "down time".

I can sleep well at night knowing that I will never "take out" more than one site at a time.