Home / server / Questions / 145208
Accepted
warren
Asked: 2010-05-26 10:48:27 +0800 CST

Best practices for re-IP'ing / migrating servers and applications

  • 772

Some of this question would be highly application-specific, but what approaches do you take when looking to migrate applications from one server/platform to another and servers from one network segment to another?

For applications that can't be re-IP'd (many exist in this category), the general answer is to nuke and pave (or extend a clusterable application, then remove the segment that needs to be "moved").

For "normal" applications (httpd, mail, directory services, etc), what are the checks you perform before, during, and after a move to ensure the health of the migrated app/server?

An example with Apache:

  1. backup httpd conf directory
  2. change httpd conf files to use new IP address of server
  3. change (or add) IP of server
  4. update DNS entries
  5. restart Apache
  6. verify web server still serves pages
  7. reboot server
  8. verify environment comes back up healthy
migration ip cross-platform

1 Answers

  1. Best Answer

    I've only had to do about 4-5 big renumbering projects so take all of this with a bucket of salt :)

    I always start with a reboot test of the current environment: If you can't bring it all down and back up again in working order migration is a pipe dream.

    Following the reboot test is an extensive firewall audit (assuming your network is divided up & everything isn't living on the same segment/subnet): Figure out which servers need to talk to each other and make sure you thoroughly understand the firewall rules that let that communication happen.
    The firewall audit should also include things like NAT/Bidirectional NAT/Port Mappings (for things like publicly accessible mail/web servers).
    From that firewall audit & a good understanding of your environment you can come up with new firewall rules for the new IP space. If the environment you're migrating has been up for a while often you'll probably also find (and close) a bunch of holes that crept in over the years.

    For migrating individual applications (and the OS configuration), your Apache example generalizes very well. As OS/Application agnostic as I can make it:

    1. Back up everything you're going to touch (configuration files, DNS, etc.) to offline storage.
      (If you're not sure what's going to be touched take a full backup of the whole damn environment!)
    2. Update firewall rules.
    3. Update name services (DNS, NIS, /etc/hosts & the like).
      If you're not using DNS, now may be a good time to deploy it...
    4. Edit system configuration files (and don't forget things like resolv.conf)
      (Make a local copy of every file before you edit it in case you screw up, especially if you ignored #2 above!)
    5. Edit app configuration files, with the same caveats as #3
      (Postgres sites especially take note of IP restrictions in pg_hba.conf)
    6. Reboot the machine at least once to make sure it survives a reboot.
    7. After everything is migrated bring the environment down & back up again
      (Including the firewalls -- just in case you missed something in #5)

    As a general order, I migrate network stuff (switch/router/fw configs) first, followed by name services (DNS) and Authentication/Authorization (LDAP, NIS, AD etc.), then "everything else in the order it should come up during a restart", which usually works out pretty well.

    • 3