Alternate Hosting

[skehrer]

I have a client that is looking for a means of insuring that their website never goes down. Is there a way to setup hosting with an alternate provider and then, if the primary host has an issue, have the web traffic routed to the alternate host until the primary host is back online?

Any suggestions are appreciated.

[mdallarosa]

I do this with some customers. I use an external DNS service that includes failover service (zoneedit). This creates an A register with a 60 second TTL.
Customer has to maintain their content replicated in both servers. Vt server is the main one, if the http service fails, the failover service detect it and automatically redirects traffic to the backup account. The failover service checks service availabilty every 5 minutes. So in the worst case the service will be unavailable 5 or 10 minutes. And the best is you have to do nothing, everything is automatic.

[newmem]

Then you gotta keep 2 copies of your databases too? And updated in real time? Isn't that very difficult to set up?

[mdallarosa]

No, the backup server connects to the same database server at VT.

[Brangwyn]

Just a heads up, Vortech have to my knowledge in the past blocked the IP of connections that they believed were running a website remotely from one of their database servers like that becuase the higher latency connections can cause some issues.

[newmem]

Originally Posted by Brangwyn

Just a heads up, Vortech have to my knowledge in the past blocked the IP of connections that they believed were running a website remotely from one of their database servers like that becuase the higher latency connections can cause some issues.

Had asked Vortech support about this today, if my ded. site hosted elsewhere can use a shared MSSQL server. Here's their reply:

"We allow databases to be used remotely. However, if you have
a completely DB-driven website that requires its own web server,
it probably needs its own database server as well. I wouldn't
recommend putting it on a shared MS SQL server."

And re: "No, the backup server connects to the same database server at VT."
- then what's the use of keeping a duplicate server? If Vortech goes down, then most likely everything goes down at Vortech. So your site won't work without the db. You would need to keep a dulicate db also at the new server to keep it always-on.

[mdallarosa]

Originally Posted by newmem

Had asked Vortech support about this today, if my ded. site hosted elsewhere can use a shared MSSQL server. Here's their reply:
"We allow databases to be used remotely. However, if you have
a completely DB-driven website that requires its own web server,
it probably needs its own database server as well. I wouldn't
recommend putting it on a shared MS SQL server."
And re: "No, the backup server connects to the same database server at VT."
- then what's the use of keeping a duplicate server? If Vortech goes down, then most likely everything goes down at Vortech. So your site won't work without the db. You would need to keep a dulicate db also at the new server to keep it always-on.

For sites that are not database driven, this will work even if Vortech network goes down. If site is database driven and database is not updated so frequently, you can make a daily backup of the mysql database and configure the http backup server to use also a backup mysql server. If the database is frequently updated and you could not replicate mysql database, then yes if Vortech goes down your site will not work. But for my experience HTTP services goes down more frequently than mysql and much more than Vortech network. Also there are some mysql administrators that allows to schedule data sync between 2 mysql servers (Navicat). I have tested with small databases and works fine.

[Brangwyn]

Had asked Vortech support about this today, if my ded. site hosted elsewhere can use a shared MSSQL server. Here's their reply:

I've personally had customers banned from remotely accessing a database server in this fashion (it was a good while back) which is why I mentioned, I'd probably not recommend ever setting up a site to operate like that also unless it's really just as as true backup site and only used in the event of a problem at Vortech (which half the time are network issues anyway meaning the solutions got a good chance of not working anyway I guess).

[newmem]

I was not planning on using a remote MSSQL server as a backup, but as the main db for the site hosted elsewhere. I could test it, and if the speed isn't that different, then what's wrong in it? It surely wouldn't be a site as popular as Google. Perhaps getting max. 2k to 5k visitors max per day.

skehrer, what solution did you decide to go for eventually?

[Brangwyn]

Once the latency to the database gets up above what it would be normally in an internal network (<1ms internal, maybe 40ms-60ms external) it just bogs things down a bit especially if many people start doing it.

And of course the latency between your web and database servers should be factored in as being ontop of the latency between your users and your webservers so the site will no doubt be a little slower. Personally, why don't you just install SQL2005 on your webserver and run it from the same box? then you can use local pipes to connect to the DB as well which will be nice and quick.

[newmem]

Originally Posted by Brangwyn

Once the latency to the database gets up above what it would be normally in an internal network (<1ms internal, maybe 40ms-60ms external) it just bogs things down a bit especially if many people start doing it.

And of course the latency between your web and database servers should be factored in as being ontop of the latency between your users and your webservers so the site will no doubt be a little slower. Personally, why don't you just install SQL2005 on your webserver and run it from the same box? then you can use local pipes to connect to the DB as well which will be nice and quick.

Current setting: We still suffer from the same latency at Vortech when we use their webserver and mssql server as we would suffer from a combination of ded-host-elsewhere webserver + Vortech MSSQL shared server.

Because in our db connection strings, we are asked to put the address of the sql server as mssqlxx.servicedomain.com, instead of just mssqlxxx. That means the webserver doesn't know it's a local server, it's making a long trip thru the internet to Vortech's mssql server - just as it would when you specify any other host's sql server name such as mssql.hostedanywhere.com.

Of course, that's my non-technical opinion. I don't know if that really happens.

MSSQL server on my own ded. box for a single site is too costly -- most ded. hosts charge $140 pm for their webserver + $250 pm for putting MSSQL server on the same box, when the site's db itself is just 150-250 MB max. So it's a whole lot of money for a small db of one site.

And isn't it always advised to keep your webserver and mssql server boxes separate, as Vortech has done here?

[Brangwyn]

Current setting: We still suffer from the same latency at Vortech when we use their webserver and mssql server as we would suffer from a combination of ded-host-elsewhere webserver + Vortech MSSQL shared server.

Because in our db connection strings, we are asked to put the address of the sql server as mssqlxx.servicedomain.com, instead of just mssqlxxx. That means the webserver doesn't know it's a local server, it's making a long trip thru the internet to Vortech's mssql server - just as it would when you specify any other host's sql server name such as mssql.hostedanywhere.com.

Actually that's not the case, routing isn't based on the canonical name, it's based on the IP address (or more correctly switched based on the MAC address), the primary reason your asked to use a FQDN in your connection strings is so that if Vortech do another IP rejig like last done in 3Q 2005 then your site will continue working without having to change anything becuase DNS will take care of resolving it for you. Sure you still have a DNS lookup to resolve it, but even that here at Vortech would be <1ms where as doing it from externally unless you put the Vortech DB Server in your local hosts file, you'r also going to have to make a trip to Vortech DNS to resolve it, and again your trip will be longer.

Requests from Vortech websites to vortech databases servers do not go outside the network becuase they're on the same network and the switches and routers know this. In virtually all instances I've tested there has been no more than 1 hop to reach the box hence latency <1ms

For example here is a traceroute from one of the webservers to MSSQL12 (you can do this yourself just using the Reverse Tracert function in the Control Panel)

traceroute to mssql12.hsphere.cc (216.157.145.72), 30 hops max, 38 byte packets
1 mssql12 (216.157.145.72) 0.781 ms 0.442 ms 0.492 ms

Now traceroute from your own dedicated server to mssql12 and see the difference.

You can pick up your own SQL2000 licenses pretty cheap from places like eBay or other license resellers certainly much cheaper than $140/pm would work our for the total cost of ownership over a short period of time by buying it second hand, alternatively there's the workgroup edition too which can be used for a single database from memory.

But do look into SQL2005 Express which is what I recommended above.

Originally Posted by Microsoft

Express has less functionality than the full version of SQL Server 2005, but Express can be used and redistributed without licensing fees. For instance, you can use it as the database engine in a custom or commercial application or as the backend for creating a data-driven Web site.

Microsoft decided to introduce Express as a way to provide SQL Server's functionality in a stripped-down way to people who might not otherwise be able to use it: students, educators, hobbyists, people on a restricted budget and so on. It's also intended to be used by people who want to write applications that use SQL Server as a kind of runtime environment, since it can be redistributed.

Express works on all editions of Windows 2000, 2003 and XP. A server edition of Windows is not required for it to run; for that reason, it can be used as a desktop edition of SQL Server. The minimum recommended system configuration is a Pentium III running at 550 MHz, 256 MB of RAM, 400 MB of free storage and the 2.0 version of Microsoft .NET Framework.

Note that Express cannot be installed on any system that has any version of SQL Server 2005 or its support tools -- i.e., data transformation services, reporting services, the tools package, and so on. It can, however, coexist with SQL Server 2000 or earlier versions such as 7.0, and multiple instances of Express can be installed on the same computer.

Running them on the same box when you have heavy web traffic and heavy database traffic isn't a good idea, but it doesn't sound to me like that's neccessarilly your situation here, you can tune SQL to use a fixed amount of memory (though when running on a box with IIS they'll tend to use around half available each which is a good compromise anyway) .. many people start off this way until they reach critical mass and need to have multiple boxes.

[newmem]

Thanks... that's extremely useful info!

[Brangwyn]

You're welcome