Top 10 Server Consolidation issues - Part 2
In this post I’ll cover points 2 and 3 from Part1, which are:
2. Application dependency or reliance isn’t known
3. Knowledge of applications isn’t readily available – often reliant on a single person
This is the scenario that is usually painted for me “…it’s our applications - we have all sort of static entries * and have lost/never had the documentation for them and no idea of the architecture”.
* explained later
Where do you start with that…well good architectural advice for the future will help, such as WSSRA but for this post let concentrate on what we can do to solve the current problem? Hopefully many of you will have developers that can assist here, either by checking the source code (I don’t envy them that job) or by studying any documentation that may exist (and I appreciate it may not be up to date!). Going forward and I apologise for the plug check out the Dynamic Systems Initiative and specifically the SDM – if don’t know what that is you should – take a look at this link for more detail.
So assuming developers can’t help, sometimes the source has been lost or even the experience when people or companies have moved on, what options are there, these are three, starting with the [potentially] easiest method and ending with the hardest [most initial cost but with potential to give the best ROI]:
1. You can choose virtualisation, as this takes the image of a running system and moves that image from a physical host to a virtual machine (known as P2V). The advantage of this method is that the application on the server (software stack) remains intact and the process of moving the server can be automated. With Virtual Server you could use the free Virtual Server Migration Toolkit (VSMT) to perform the P2V function. This results in the application being re-hosted but it keeps the software stack intact (which is a easy option) however this may not solve all your problems such as running an outdated OS etc…
2. You could take the application re-install on a clean server and see if it still works – the level of success of this method will vary but is likely to be low. However it should show up quickly any dependencies such as database lookup or middleware reliance. This option may also encompass a Operating System, move to the latest version as well
3. Re-code the application to allow for consolidation, co-hosting or just to re-platform. This is a great option as it gives you the option to resolve many potential issues, however this tends to be the last resort unless and it’s a big unless you are about to rewrite the application anyway for business reasons, more of this in a later post in this series (yep it’s turned into a series).
This could give you the best future payback as the new application can be aligned with your architecture, run under your latest governance, and be designed from the ground up to fit into a Dynamic architecture.
What other issues could you face? I mentioned at the beginning of this post the issue of “static entries”, by that I mean the common issue of hard coded IP addresses or host names. For server consolidation this can also open another can of worms (as if we needed that) which is the same issue but in the clients. This normally rears it head when you are making headway and then have to look at modifying all the clients to point to the consolidated environment on a new server or at a new IP address – it could also mean updating all your client software in combination with the server! Altering the client workstation configuration or server re-provisioning, also means that you have to consider the other issues of bandwidth and latency. Modern networks normally are well instrumented, so it’s a good idea to get the network team involved in your planning and discussion making. This is especially important if you're consolidating sites as part of the exercise.
Anyway enough of the gloom, here is some practical advise to identify application inter dependency and to recover knowledge about your applications. One thing you can easily do is to monitor the application, there are many tools for this but I would recommend these from www.sysinternals.com as a great starting point. The specific tools are Filemon, Regmon and TCPView (the last of which I have posted about before) this one I find the most useful. Filemon and Regmon do as their names suggest allow you to monitor an application to see what files (Filemon) are being opened or closed and which areas of the registry (Regmon) are being accessed. Note: I’m not recommending this approach for every application you have, only those that are unknown or those that you are having issue with. TCPView may be of the most use (or using the NETSTAT command that is built-in to Windows) as this will highlight where an application is communicating to/from at a TCP level.
I'm sure I've missed loads...what do you think?