61

Here's my scenario: I'm a developer that inherited (unbeknownst to me) three servers located within my office. I also inherited the job of being the admin of the servers with a distinct lack of server administration knowledge and google / ServerFault as a reference point. Luckily, I've never actually had to come into contact physically with the machines or address any issues as they've always 'just worked'.

All three machines are located within the same data room and serve the following purpose:

Machine1 - IIS 8.0 hosting a number of internal applications
Machine2 - SQL Server 2008 R2 data store for the internal applications
Machine3 - SQL Server 2008 R2 mirror store of Machine2

All three have external hard drives connected that complete back ups frequently.

I've been informed that all three need to move from one data room to another within the same premises. I wont be completing the physical moving of the hardware, that'll be handled by a competent mover.

Apart from completing a full back up of each, what considerations do I need to make prior to hypothetically flicking the power switch and watching my world move?

I'm aware that it's far from ideal having all three located in the same room / premises but that's past the scope of this question.

Gareth
  • 735
  • 5
  • 10
  • 1
    Network will be the most definitive factor in this move. If you don't have network engineers, digging up info you need will be more critical for your job scope. Aside from that, get a label printer, label everything, you want to make sure you plug peripherals back correctly. (In this case at least external HDD) –  Aug 22 '16 at 14:22
  • There's one way to be sure - do you have power and network cables that reach from the old location to the new location? ;) – A E Aug 22 '16 at 18:09
  • Do you want to administer the servers? I would seriously consider selling them and hosting in azure/as – spuder Aug 22 '16 at 18:24
  • 3
    Even unrelated to this move, you already have a plan what will you do if one (or all) motherboards/power supplies/disk die? (because it will eventually happen) – Dusan Bajic Aug 22 '16 at 20:33
  • 5
    @spuder maybe they need the app available without Internet (they say it's an internal application) or they just don't want the NSA peeking in. The cloud is not a silver bullet. – André Borie Aug 22 '16 at 21:43
  • 27
    This isn't enough for an answer itself, but I'd suggest doing a soft power-down and power-up before the move so that you know what the servers do when they're powering on successfully. There may be some scary beeps or ignorable error messages you won't know to ignore if you haven't power cycled the servers before. When you know what a smooth power-on looks/sounds like, and how long it takes, you'll be in a better position to judge if something's very wrong after the move. – Stefan Mohr Aug 22 '16 at 21:44
  • 2
    Do a reboot of each machine in turn and hope that it comes back to life without errors before you move! – hookenz Aug 23 '16 at 04:20
  • 7
    @Matt at least he admits being clueless and tries to learn which is a good thing. I've seen far too many cases where the admin is a complete idiot but doesn't even realize it. – André Borie Aug 23 '16 at 10:37
  • 2
    Definitely reboot first. That way you know if it was broken by the move or if it was _already_ broken by some dubious config. – Sobrique Aug 23 '16 at 15:59
  • 2
    2008 R2 suggests old machines -- **make sure** you have a **good** contingency plan for when (not if) one of them gives up the ghost. – Yet Another User Aug 24 '16 at 00:05
  • Not exactly answering the question, but an alternative suggestion: those versions are so old, you might want to consider building *new* servers and migrating the services to the new ones. Migrate your SQL Server data to a modern SQL Server (2008 vs. 2016) and anything else you might have to do. Re-building the servers will also give you a lot of necessary tribal knowledge that was never give to you at the time, so you should be more comfortable with the services moving forward. – Christopher Schultz Aug 24 '16 at 19:10

8 Answers8

61

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.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • 2
    +1 for Chopper3 - I'd also add that depending on how your network is configured, there is just a small chance that the MAC addresses of your network cards won't be released from the old switch and Internet might not work depending on how the network is built. I know this might not happen if the switches are properly configured, however I've worked in a large environment and this happened quite often and the network engineer had to manually clear the MAC entry. – Mugurel Aug 22 '16 at 12:07
  • 4
    Take a photo of the backplane before dismantling. Saves a laod of pain. – Sobrique Aug 23 '16 at 15:58
  • @Sobrique - what backplane? – Chopper3 Aug 23 '16 at 18:37
  • 1
    Everything. Just take photos on your camera phone of where all the cables go, and what's plugged in and what's not. (Assuming you're allowed those in the DC). Really good to double check later how 'things looked' if something wierd is happening. – Sobrique Aug 24 '16 at 08:02
  • 2
    Ah so 'ports' then - backplane often refers to something entirely different – Chopper3 Aug 24 '16 at 08:34
  • 2
    @Chopper3 Backplane *always* refers to an internal hardware component and never "the back of the server's case." Except when it means a failed social network. – Christopher Schultz Aug 24 '16 at 19:13
  • I recently shifted data-center of my org to a new building. Proper **documentation** goes a long way to help. We not only did have a detailed schematic of the entire data-center, but also the ports, cables and the works were all properly physically **labelled** (and/or **ferruled** for cable ends) and in-sync with the schematic. – Abhitalks Aug 26 '16 at 12:09
27

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.

chue x
  • 401
  • 4
  • 7
18

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.

Sven
  • 97,248
  • 13
  • 177
  • 225
  • 7
    +1 backups. They shouldn't be in same location, also the server that is backed up should not have access to backup media, else a mistake/malware/sabotage/ransomware on one of the servers can destroy backups, too. Right now might not have budget, but put it on your list of must-do. –  Aug 22 '16 at 14:27
16

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).
Makyen
  • 263
  • 2
  • 4
  • 10
7

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.

chugadie
  • 201
  • 1
  • 5
2

Utilize your "Disaster Recovery" servers. Switch over to them to handle the load while you move your production servers. With properly configured DR equipment you can do the move in the middle of the day without seeing much downtime (up to 15 mins). As the disaster recovery servers should be configured in the same manner as the production servers. If you don't have DR equipment, I highly recommend getting them.

Think of it this way: while your corvette is getting a tune up, use your minivan to get through the day.

Software_Programineer
  • 146
  • 3
  • 6
    You're assuming a lot about a company that surprises an inexperienced admin with three servers. – RoadieRich Aug 24 '16 at 18:36
  • Absolutely, I'm assuming a fully functioning properly setup server lab. Or at the very least a place that has some old servers(or even pcs) still laying around collecting dust. Re-config them just to do the move. – Software_Programineer Aug 25 '16 at 19:30
1

One thing I don't think has been mentioned is physical security of the new home of the servers. What was the room used for before and who has keys to it? Is there adequate security (alarm systems, cameras, etc.).

caletron
  • 11
  • 1
1

Some considerations in addition to the other answers:

  • Are the applications linked to other ones by e. g. nightly exchange of data by file or by use of webservices? What are the consequences when the applications are not available? Can related applications cope with this or do they fail or even produce wrong results due to lack of information from your applications?

  • Is a downtime acceptable for your users, company or even clients? How long may it be?

  • I think it is a good idea to have a plan for a rollback. You can use it in case of a problem that can't be resolved quickly, e. g. a network problem. You will probably need to keep the mover available for the case of bringing the hardware back.

  • Do your applications lead to high network traffic and does the network have to be prepared for this (probably much more unlikely a problem than issues with addresses and firewalls)? If you have real time applications (e. g. video conference software) latencies will be important.

  • The servers must fit into the server rack if you have one.

mm759
  • 111
  • 2