Moving Servers Within The Same Building

Solution 1:

Genuinely interesting question, well asked :)

There's a few things you need to check before this move, some easy, some hard.

Power - check that the new room has not only the right amount of power outlets but that they're the right type - as in physical connector type and if the current location allows for different power phases per server to protect against single phase failure then I'd strongly urge you to replicate that also in the new location.

Cooling - you need to check that there won't be an immediate or gradual build-up of heat that will lead to overheating and potential server shutdown. You can usually look up the maximum power (in watts) or heat (in BTUs) that each server can draw from the manufacturers website - let your building manager know this and get a written confirmation from them stating that the cooling in that location will cope.

Networking - this is the hard one - not only does the same number of ports need to be replicated between old and new location but so does their type, speed and most importantly configuration. This last point is the key - there was a time when almost all ports in a network were pretty much equal - I'm old enough to remember those times! but these days the number of port configurations and the place in the network that any one port can be in is astronomical, you need to make sure that your network people replicated EVERYTHING to be identical from old to new - again get this in writing as this isn't easy. If something goes wrong with this move I'd put money it'll be on the network ports not being identical, it happens all the time.

'Other connections' - do you know if your servers have any other connections than power and networking? perhaps they have Fibre-Channel links to shared storage, KVM links to a shared management screen - again if they do you need to replicate these identically.

Other than that feel free to come back here with any more specific questions, and I hope the move goes well.

Solution 2:

Other answers cover the technical aspects of the move. You may also have to consider some other things.

Make sure users know that their applications will be down during the move. You will want to schedule the move, perhaps during non-working hours, so that you minimize the number of people affected.

Have a knowledgeable person (or persons) test the applications after you bring up the servers. Have them do some sanity checks to make sure the applications work as expected.

After the testing, tell your users that the move is finished and have them let you know if they have any problems.

Solution 3:

It's quite difficult to tell and borderline "too broad" for our format. The most important thing you need to check is if you need to reconfigure your network in any way of if they can keep running with the same addresses. Even if they can keep the same addresses, make sure they are not configured via DHCP and/or verify the DHCP server will be available at the new location.

Side note: As you already stated, having the SQL server and it's mirror is far from ideal. However, having the backup drives at the same location is really dangerous. You need to have your backup in a different physical location.

Solution 4:

Other answers have good pre-move considerations. However, you should also be planning how you organize the actual move. From the fact that Machine3 is a mirror of Machine2, it looks like uptime is a significant consideration for the SQL Server 2008 R2 database(s). The fact that it is a mirror provides you with an opportunity. The reason for the existence of a mirror is to be available when the primary server is not. That includes not being available due to maintenance, which includes moving.

Make a plan:
You should make a written plan for how the move will be carried out. You may need to be able to provide this plan, or parts of it, to people handling portions of the work (e.g. the movers). This plan should include all pre-move activities, the actual move, and post-move actions (e.g. verification of functionality).

Move Basics:

  1. Move Machine3 (the SQL Server mirror): Get it fully operational. Verify re-sync.
  2. Move Machine2: Get it fully operational.
  3. Move Machine1: Get it fully operational.

More detailed description of the move:

The following includes two methods (Path A and B) of using Machine3 to test the connections for Machine1 and/or Machine2. You should only use one method. What way to do so, or even if to use either, depends on information not contained in the question (e.g. physical separation of the final machine locations, physical size of the machines, length of network/power cords, availability of extensions for same, similarity of network port configurations, uptime needs, etc.). Using Machine3 to test these connections potentially allows higher uptime for Machine2, but particularly for Machine1, which has no mirror. You can choose to use either method, or neither.

  1. Move Machine3 first.

    • Leave Machine1 and Machine2 in place for now.
    • Backup Machine3, then shut it down
    • Get Machine3 completely moved to the new location.
    • [Path B: Not used if you are going to use optional step #2.] If the network and power configurations for all machines are identical: Put Machine3 where Machine1 is planned to end up using the connections intended for Machine1.
    • Get Machine3 back up and running. In the new location, verify that it is functioning normally as a mirror of Machine2. This will provide physical verification that the configuration of all issues (power, network, etc) are functional in the new location.
    • Resolve any issues which come up.
    • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.

  2. Path A: (Optional):

    • Use Machine3 to test all facilities intended for Machine2 and Machine1.
    • Shut Machine3 down and move/switch to using the position/connections for Machine2, (verify re-sync) then Machine1 (verify re-sync). If you planned to do this, then Machine3 should have initially been set up with the connections intended for end use by Machine1 or Machine2, so you to not set it up first in the end location for Machine3 and then change it 3 times, but only 2 by starting with it using the facilities of one of the other machines.
    • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.

  3. Move Machine2.

    • Your practice with Machine3 should make this much smoother.
    • Backup Machine2, then shut it down
    • Move Machine2 to the new location; make all connections
    • Resolve any issues which come up.
    • Verify that Machine2 has fully re-synchronized with Machine3 prior to proceeding.

  4. [Path B: Not needed if you tested all connections with Machine3 in optional step #2] If now have Machine3 where Machine1 is to end up:

    • Shut down Machine3.
    • Move it to where it is planned to end up (out of the location you intend Machine1 to be located).
    • Resolve any issues which come up.
    • Verify that Machine3 has fully re-synchronized with Machine2 prior to proceeding.

  5. Move Machine1.

    • Having moved Both Machine2 and Machine3 (and hopefully tested the actual connections Machine1 will be using by having Machine3 use them temporarily), this should be the smoothest of the moves.
    • Backup Machine1, then shut it down
    • Move Machine1 to the new location; make all connections
    • Resolve any issues which come up.
    • If something goes wrong with the facilities in the position that Machine1 is supposed to occupy, you have the option of using the facilities where Machine3 is now located. Hopefully you were already able to test all facilities in the Machine1 position by having it already used by Machine3 for a time (Path A or Path B).

Solution 5:

If any of the servers' IPs will change then and connections are made to the SQL box via DNS resolution then you will need to schedule a change to the DNS records at the same time as the move.

Things you should know about the intranet software and databases:

  • Does the intranet software connect to the SQL Server via IP, NetBIOS, or DNS?
  • Do the SQL Server user accounts used by the intranet software have authentication limited to traffic coming from an IP?
  • Do employees at your company access the SQL Server directly from any spreadsheets or reporting tools, if so, how do they define the DSN?

If you don't get the exact same IPs, or if you end up on a different sub net, you will need access to change the source code or configuration files for any apps that connect to the SQL server. People could be relying on undocumented and direct SQL access for ad-hoc reporting.

Tags:

Hardware

Related

How to make EC2 user data script run again on startup? Windows server. The difference between organisation units and groups? (Active directory) Windows Update 800F0922 openssh - Adding an ssh key from putty to authorized_keys Error creating GCE load balancer: requested address ip is neither static nor assigned to LB Creating a docker mysql container with a prepared database scheme Shrink partition to exactly fit the underlying filesystem size What are the performance implications for millions of files in a modern file system? How do I set destination permissions with rsync (chown chmod) IPv6 support or alternative for aws vpc instances The option to "Launch slave agents via Java Web Start" is missing from new node configuration, how can I add it to the options menu? When do you have to use quotes in the configuration?

Recent Posts