5

Is there a preferred method of gracefully upgrading a web site? I have a completely new code base ready to go on a site, but updating it will take several hours. I don't want the site to be down the entire time with a "Upgrading, be back soon!" message, but neither can I leave the current site up while the new one is put in place.

The only way I can think of that might allow for a graceful upgrade is through the use of two servers, but this would get more expensive.

GEOCHET
  • 21,119
  • 15
  • 74
  • 98
Brad
  • 1,645
  • 2
  • 11
  • 11
  • Are there data or schema changes to the database to be deployed as well? – Jeremy Stein Oct 08 '09 at 15:17
  • 1
    Several hours? Wow, that's a major update. What is taking several hours? Some database migrations or... ? – marcc Oct 08 '09 at 15:17
  • 1
    The only thing I could say is to do it at like 3 in the morning when everyone is asleep. If you leave the current site up while upgrading you risk data corruption, if you take it all down you inconvenience some people, so just do it in the middle of the night. Put up a message that says "The site will be inaccessible from 1am until 5am today, we are sorry for any inconvenience." – somacore Oct 08 '09 at 15:21
  • @somacore: 3 in the morning where? http://www.timeanddate.com/worldclock/ – NickFitz Oct 08 '09 at 15:34
  • @NickFitz Eastern Australia, currently. Wait, that means I should be asleep! ;) –  Oct 08 '09 at 15:49

7 Answers7

10

Planning to "gracefully upgrade your website" doesn't start when you're ready to deploy. It starts very early in the design of your application. That means you have to build an application that can be upgraded gracefully, and also having the infrastructure in place to support that upgrade.

You have provided few details and are asking a vague, but important question from random people on the internet. This leads me to believe that "upgrading gracefully" was a last minute concern (like 23 minute ago).

Your question, "Is there a preferred method of gracefully upgrading a web site?" can only be answered as, "Yes, but I do it way differently than you do."

rmontgomery429
  • 14,660
  • 17
  • 61
  • 66
  • In hindsight, the previous application was simply awful and provided no way to be gracefully. It was decided (but people other than myself) to start from scratch. That's where I came in. What I wasn't told was that after I had completed the project, they would need it deployed without any down time. Since my original post, I have talked to the client and they have agreed that a few hours of down time from 3-5am is acceptable all things considered. In the future, I will take this into consideration. – Brad Oct 08 '09 at 19:45
  • 1
    @Ryan: Are there any books that can be referred on designing applications in this regard, i.e. applications supporting graceful upgradation? – Srikanth Vittal Mar 07 '12 at 14:46
1

There's a number of tactics you can use - depending upon the time/resources you're willing to commit to the upgrade.

It might be possible, depending upon how you're performing your migration, to do this with absolutely zero down-time.

The more complex your application/site, the more complex the migration strategy may be if you want no downtime.

We've achieved zero down-time migrations by:

  1. Setting up new server(s) with the new version of the site and database.
    • Altering the load-balancer to split traffic into two pools new-app, and old-app.
    • Configure load balancers begin sending traffic to the new-app server(s), but keep existing sessions on the old-app server(s)
    • New sessions on new-app check to see whether the customer-data has been migrated, and if not - quickly does that.
    • Progressively shutting down "old-app" servers as load falls off, upgrading to the new-app, and adding to the new-app load balancer pool.
    • As sessions end, the customer data is migrated to the new database.
    • As load permits, migrate inactive customer data to the new database.

Of course, this is more complex - as we needed to maintain access to customer data in two environments and progressively migrate.

It does permit us though to roll-back changes should some issue be noticed - eg excessive CPU or Memory usage on one of the new-app servers.

For a smaller site where you don't have the budget for additional servers, you may be able to achieve this by simply using multiple IP Addresses, or some form of internal load-balancing software to route requests to the old, or new site. This can complicate matters more.

If you're not able to run the old app, and new app off the same data store (backend webservices, database, etc) - then your apps would need to be aware that they would need to sync data between old/new - eg during save/update of customer-data, the write would need to occur in both locations.

1

Several hours is much, if there is a lot of converting in the database you can first take a copy of the database, finish converting, set up the new site (but with a slightly old db), look on what have changed since you took the copy, convert that too (should be faster than the big dump if you don't have a lot of changes) and insert it into the new database.

Just don't forget to backup!

Erik
  • 53
  • 4
0

If it's only the database you are upgrading, just make a new one and switch back as soon as it's ready. If you are talking about uploading the code, upload it to another directory and mv it when it's ready. It's shouldn't be a problem if you have a similar setup on your development environment.

You can also rent a very cheap server like those at 20euro/month (kimsufi or something) and do your upgrade.

Roch
  • 21,741
  • 29
  • 77
  • 120
  • 1
    The problem with this would be that the site still needs to be offline or at least read only, right? Or else you'll lose all transactions that happened during the upgrade. – marcc Oct 08 '09 at 15:21
0

I think that, whichever way you go with this, it is absolutely necessary to have the full cooperation of your web hosting and domain name provider.

A rough procedure would be to:

  1. Rent a new server with a different IP address, which will be where you'll deploy the new site. Or if possible, create a test subdomain within your site that is inaccessible to the public.
  2. Deploy your site in the new server/subdomain. Perform all necessary testing with your new site using the IP or your subdomain first.
  3. When you're sure everything is okay, issue redirects first to your new server/subdomain.
  4. Redirect your DNS to the new IP address, or fix it in such a way that you can make your main domain now point to the original location of the subdomain.

Ideally nobody would even notice that your site was down, or if it has down time, it will only last a few minutes.

Jon Limjap
  • 94,284
  • 15
  • 101
  • 152
  • But what about transactions (purchases etc) made during the transition. They're reflected in the old database not the new one. – djna Oct 08 '09 at 15:24
  • You can always migrate those transactions later. – rmontgomery429 Oct 08 '09 at 15:27
  • sure you *can*, but you'd better not forget! But later may be too late, two people just got a chance to buy that very last limited-edition gold-plated Joel statue you had in the inventory. – djna Oct 08 '09 at 15:29
0

Sounds like you want to have your cake and eat it.

If the upgrade is a manual job that takes several hours, why don't you speed it up by scripting the job.

tomfanning
  • 9,552
  • 4
  • 50
  • 78
0

This is probably something you needed to have already "designed in" to the current release.

Can it be segmented so that some parts (eg. catalogue) are available, but others (eg. purchasing) are being upgraded?

Can a read-only version be created using a cache?

Or, surely there are times of day when a service outage is acceptable? Work a Sunday evening? Even quite major websites have some maintenance windows during which pieces of functionality are unavaiable.

djna
  • 54,992
  • 14
  • 74
  • 117