Chris Baumbauer: Personal Musings

Blogs

Ordered list of blogs will go here with a widget

Migrating infrastructure: Jumping from flat to flat

Posted: Nov 12, 2015 3:15 am


As all stories go, this one is the tale of a move between apartments. While not nearly as common nowadays with a lot of geeks running their personal servers on some kind of cloud based offering, there are a few die-hard people (such as myself) who insist on running their own server from home. If you move on a regular basis, then this is more than likely old info, but for some this may be useful. So hang on, and get ready for the fun that is moving.

Essentially, what you get to look forward to are two components: * Migrating physical equipment * Possible migration of IP addresses

The reason why IP address migration is a possibility is that it will depend on whether or not you get to keep your current ISP or if your ISP opted to give you a dedicated VLAN with your static IP address assignment. There are services such as DynamicDNS that handle this kind of situation, but it has always struck me as overkill, and doesn't protect from the eventual case of your ISP giving you an address on a private subnet in the future. I know for DSL, you will definitely get a different IP address, but apparently AT&T's U-Verse goes the VLAN route which makes moves within the same city much easier.

As to the physical equipment, there will be downtime. No way around it, but luckily since you're running things at home, this shouldn't pose too much of a problem, right? Since I do run my primary mail/web server as well as some client code, this does require some additional planning. Luckily, I managed to clone an older system as a VM, and will usually bring that older system out during the move to act as a temporary host. Nowadays, this functionality can easily be reduced to a raspberry pi. With it configured enough to host the personal website, and enough details to run my mail/DNS at the new location, I'm ready to go.

I will leave at least a week of overlap between the new and old locations explicitly to ensure that the network connectivity is up and running so that I can bring the essential network gear and temporary system. Once everything is plugged in and confirmed to be working at least from the new place, then I can take a more leisurely approach towards shutting things down at the old apartment. Funny thing with the ISPs here is that sometimes, the installer arrives early, and other times not, but this way, you can be reasonably certain that your downtime will be minimized once the cut-over actually happens.

Now that moving day has come and gone, and things are installed, and appear to be working properly, there is one thing you still need to do before cutting back over to your primary system, and that is to sync the data that may have accumulated during the break. Mainly from the email server, but if I'm in the middle of doing client work, I will have an updated code repo that will need to be re-synced as well. As my network infrastructure sits behind a firewall/router box, I can do the sync, and possible re-sync prior to switching which host will be listening on a given port. With the transition done, then its safe to power down the temporary box, and keep it around for the next move (while hopefully kept up to date on the software patching).

That's pretty much it. I've also had a friend host a VM of my mail/web system for a few days during a stretch when I moved across the state, and couldn't guarantee the overlap, but the approach is still the same.

Topics: moving, infrastructure, devops,


Return home