Determining application interdependencies is a key step in planning a move, and Device42 has been able to help you with this step for a long time. New features in v11.6.0’s Dependency Diagrams make it much easier to filter out objects that aren’t important to your move, and allow you to drill down through dependencies to isolate exactly the group of objects (i.e. the “move group”) you care about on a per-application and per-device basis. Each move group makes up a set of machines that will then be migrated together, segmenting the move into smaller, logical pieces.
The steps to define a move group are as follows:
- Choose an Application component or Device that you’d like your move group to include
- Bring up the CI for the device you’ve chosen, or for the device that hosts the Application component you’ve chosen
- Head over to the “Topology” view for the aforementioned device
- Filter and / or drill down to get a view that encompasses all related dependencies
- Optionally – export the view or service dependencies report for your move group
Whether you choose to begin your groupings from application components or from the device level is completely up to you, as both are perfectly valid approaches and will produce the same end results. The following examples will demonstrate both approaches leading to the same end result.
To begin, head to the “Software” menu in your Device42 instance, and choose “Application Components”:
From the list of application components, choose an application that you are interested in migrating. From the “View Application Component” details screen, select the “On Device:” link to bring you to the details page for the device that is hosting your chosen application component. For this example, the application component “Oracle Database Server 1” is “On Device: oracle-db-1”.
Next, choose “Topology” in the upper right hand corner:
We are now presented with an Impact Topology Chart for the device (in this case, oracle-db-1) that is hosting the application component we began with (Oracle Database Server 1), as shown below:
This high level diagram may look familiar to those who have previously worked with Device42’s Impact Topology Charts – with the addition of the “+” or “-” buttons that now appear on certain CI’s which allow you to drill down through the dependency chain, displaying just the level of detail necessary.
The view on the left hand side shows all devices that are dependent in any way on oracle-db-1, while the right hand side shows oracle-db-1’s service & connection level details. By expanding (choosing “+”) on USNHCTB0003, we can show more detail about the services and connections on it; doing so also reveals the connection to the web server, “webserver.dev”, and expanding webserver.dev reveals that it is also dependent on another server, “app21.device42.pvt”, as can be seen in the image below:
This expanded view provides detail on all the components in our “move group”, and all the information needed to determine exactly which services this move group provides. We can see that a Java application (Tomcat) is acting as middleware for the front end web server “webserver.dev”, all of which are relaying data from “oracle-db-1”. Furthermore, we can see at some point a second website (site2.com) was added to “webserver.dev”, which appears to be dependent on a second mysql instance running on “app21.device42.pvt”. We now know to investigate to ensure site2.com is still in use, as move time would be the perfect time to remove this tertiary dependency, or to relocate the site to it’s own server if desired.
Optionally, now would be a perfect time to export a picture of the dependency diagram above for record and further planning purposes, and/or to export the service dependencies report as well. Continue by repeating this grouping process for each server or application component that is a candidate for the move, and you’ll soon have all the groups necessary to plan the actual steps involved and order of your upcoming move.
Data center moves are large, complex projects which must be well planned to avoid embarrassing and costly downtime. While not much feels better than a move gone right, not much feels worse than a move gone wrong. To ensure your move falls on the former end of that spectrum, you’ll want to break your move into smaller, manageable chunks, and execute them in parallel where possible, and in a predetermined order where dependencies deem it necessary. New features in Device42 simplify the creation of these move groups, and hopefully this post’s examples of how to go about defining a move group prove helpful when planning your next move. Do you have any questions that weren’t fully addressed by this post? Comments, suggestions, or observations? We would, as always, love to hear from you! Feel free to leave a comment below, or feel free to drop us an e-mail any time. We look forward to hearing from you. Until then…
Good luck & Happy Migrating!
-Your friends at Device42