Infopackets Back Online; New Server, and More!

Dennis Faas's picture

Dear Infopackets Readers,

Our web server was shut down on September 23rd around 12:05AM EST as part of a mandatory upgrade (the operating system was no longer supported). Since the server was 6 years old, I decided to retire it and upgrade to a new server for the same cost. This also allowed me to upgrade my operating system at the same time (but also required all files be transferred and reinstalled to the new server). Not fun!

Read on to find out exactly what happened over the course of the past 4 weeks.

Connectivity Lost Starting September 21st

Access to our website was blocked from approximately September 21st (when DNS propagation began to the new server) until last Thursday (September 29th) around 9PM EST, when I was able to finish with one of the last pieces of software installations.

The new server has moved to another data center and resides on all-new hardware (some of it bleeding edge).

400 Hours to Backup Files, Move, Configure New Server

I've been working on the migration since the beginning of September, and was expecting it to be completed by the end of the month.

Unfortunately, I hit *many* issues along the way which required many Trouble Tickets to the hosting company, along with a huge dose of research. I was also under pressure to get this done before my next billing cycle (on September 28th) or I'd be charged another $300 for a month's rent for the old web server which wasn't going to be used.

I literally worked on the new server upgrade / conversion for over 400 hours in a 4 week time period (that equates to approximately 14.3 hours a day for 7 days a week). I did not get much sleep. And no, I'm not over exaggerating: it took 400 hours and I did it non-stop. Insane? Yes. Necessary? Yes.

In all, the transfer from one server to another (in two separate locations) was done by using a secure shell (SSH), which is similar to an MS DOS prompt, or 'cmd' under Windows. There was no "point and click" to drag and drop files.

In short, I had to:

  1. Set up a virtual private network (VPN)
  2. Install Linux on a VPN using virtual machines (VM) using XenServer -- not fun if you've never done it before
  3. Configure each VM to work with public and private network subnets
  4. Move all Infopackets files to the new server / virtual disks
  5. Install Plesk (our website control panel) on a VM; configure DNS
  6. Reconfigure Plesk for Infopackets and its subdomains
  7. Put all Infopackets files back where they were before
  8. Reinstall all the programs on the new server
  9. Test all programs to ensure they work properly
  10. Replace programs that are no longer supported, which requires reprogramming portions of the site by hand

And of course, none of this was as easy as 1-2-3. I ran into problems at every stage, and I had to do a lot of testing in between steps to ensure this setup was going to work (or I'd have to find something else that would).

New Server Setup Uses Virtualization

Originally I was going to run a similar server setup as the last server (basically, 1 web site on 1 server), but then realized that this type of setup isn't very good for software development / server programming, which I desperately need help with.

That said, website software developers often need unrestricted access to a server to get the job done quickly and efficiently -- but, this is, of course, a major security issue. As such, delegating privileges and setting up the server for guest access (especially for development purposes) is a major pain.

The solution I decided on was to use a virtualized environment that allowed me to make a copy of my existing web server (minus sensitive files), assign it a different IP address, and allow a developer (for example) unrestricted access to a 'development' server. Using this type of setup, Infopackets can remain fully functional while a software developer uses his own version of the server to make changes.

This type of technology is also referred to as 'sandboxing' as the two servers would operate autonomously.

Moving Servers: A Major Project

The most difficult part of the server transfer was setting up the operating system on the new server. That's because the new server setup (which runs on XenServer, explained further down) operates on a virtual private network (VPN), which means access to the outside world is restricted.

Without getting into too much technical detail: the VPN helps to keep things secure while I configured my server installations and management, but it also added an incredible layer of complexity in terms of installing an operating system on a virtual machine (by remote).

New Server uses Citrix XenServer

In a nutshell, the new Infopackets web server resides in Texas and runs the 'XenServer' bare metal server software. Click here to see a cool video of what XenServer does.

It's called a 'Bare Metal' server because it's not a full-blown operating system that has all the features an everyday user would need. XenServer, has essentially been stripped down to the core, and has only one major job: to supervise (or, 'Hypervise') virtual machines that run on the system.

... (This article has been cut into a 2 part series. Click here to continue reading).

| Tags:
Rate this article: 
No votes yet